iPAS Exam Preparation Notes - Information Security Engineer

While preparing for the iPAS AI Application Planner (Entry Level) exam recently, I took some practice exams for the Information Security Engineer (Entry Level) from last year and found that I passed both subjects, so I decided to register for both. While using Gemini Gem to drill practice questions, I noticed that some terms and details are easily confused, so I decided to have the AI help me organize them into a set of notes, supplemented by my past engineering experience.

The following are just personal notes, and the content is not guaranteed to be entirely within the scope of the entry-level exam. I intentionally increased the difficulty in the Gemini Gem instruction settings, and the difficulty was raised in each round (20 questions per round, 5 rounds in total), so I suspect it covers more than the entry-level scope but does not cover the entire intermediate scope.

These notes are a collection of thoughts as they come, and I may add to them at any time while practicing. Additionally, there are many code snippets and command sections in the notes, which are included for easier understanding or for reference when needed, so I have collapsed them using details tags.

Basic Concepts

Fundamental Principles and Terminology of Information Security

CIA Triad (Core)

Concept	English	Description	Control Measures
Confidentiality	Confidentiality	Ensure information is accessed only by authorized parties	Encryption, access control, data classification
Integrity	Integrity	Ensure information is not modified without authorization	Hash verification, digital signatures, version control
Availability	Availability	Ensure authorized users can access information in a timely manner	Backup, disaster recovery, load balancing

Extended Security Attributes

Concept	English	Description	Control Measures
Authenticity	Authenticity	Verify the authenticity of the information source	Digital signatures, PKI, multi-factor authentication
Non-repudiation	Non-repudiation	Ensure actions cannot be denied after the fact	Digital signatures, audit logs, timestamping services
Accountability	Accountability	Ensure actions can be traced to a specific individual	Identity authentication, access logs, separation of duties

AAA Framework (Authentication, Authorization, Accounting)

Element	English	Description	Control Measures
Authentication	Authentication	Verify user identity ("Who are you?")	Account/password, MFA/FIDO2, biometrics
Authorization	Authorization	Determine accessible resources ("What can you do?")	RBAC, ABAC, OAuth 2.0
Accounting/Auditing	Accounting	Record user actions for tracking ("What did you do?")	Audit logs, SIEM, NetFlow

CIA vs AAA

CIA describes the security attributes that information should possess (protection goals); AAA describes the three stages of access control (implementation mechanisms). The two are complementary.

CIA and AAA Relationship Diagram

Asset Value Assessment Criteria

Value Type	Assessment Element	Quantification Method	Example
Direct Cost	Reconstruction, procurement cost	Monetary value	Software license fees, hardware equipment costs
Indirect Cost	Operational disruption, reputational loss	Revenue loss estimation	Loss per hour of system downtime
Legal Cost	Regulatory compliance, penalty risk	Potential fines	GDPR can fine up to 4% of annual turnover
Competitive Value	Intellectual property, trade secrets	Competitive advantage assessment	R&D results, customer lists

Defense in Depth

An architectural strategy of multi-layered security controls, providing protection even if a single layer is breached. The concept is similar to the layered defense of an ancient castle: if the wall is breached, there is a moat, and further in, there is an inner city and arrow towers. Each layer consumes the attacker's time and increases the risk of exposure.

Layer	Control Measures
Governance Layer	Policy, Security Awareness Training
Physical Security	Access Control, CCTV
Network Perimeter	Firewall / IPS (Intrusion Prevention System) / SDP (Software Defined Perimeter)
Internal Network	Zero Trust / NAC (Network Access Control)
Host Security	EDR (Endpoint Detection and Response) / AppLocker (Application Whitelisting)
Application Security	WAF (Web Application Firewall) / RASP (Runtime Application Self-Protection) / SSDLC (Secure Software Development Lifecycle)
Data Security	Encryption / DLP (Data Loss Prevention)

Security Governance Document Hierarchy

Level	English	Nature	Example
Policy	Policy	Explains "what to do" and "why," without specifying technical details. Approved by top management, mandatory, violation constitutes non-compliance.	"All data transmission must be encrypted"
Standard	Standard	Explains the "minimum technical threshold to meet policy requirements," mandatory. Specifies specific versions, algorithms, or settings, violation constitutes non-compliance.	"Use TLS 1.2 or higher"
Procedure	Procedure	Explains "how to execute," lists sequences of repeatable operations. Mandatory, personnel must follow steps, deviation requires formal approval.	"Account Application SOP"
Guideline	Guideline	Provides recommended practices, non-mandatory. Personnel can judge whether to adopt based on context, deviation does not constitute non-compliance.	"Recommended password length of 12 characters or more"

Governance Document Hierarchy Diagram

Information Ethics: PAPA Theory

Proposed by scholar Richard Mason in 1986, defining four ethical issues in the information age.

Abbreviation	Issue	Core Question
P (Privacy)	Privacy	Individuals have the right to decide whether to disclose their own information
A (Accuracy)	Accuracy	Responsibility for the authenticity and correctness of information
P (Property)	Property/Ownership	Ownership of information intellectual property rights
A (Accessibility)	Accessibility	Under what conditions is one qualified to access information

Difference between Accessibility and Availability

Accessibility ≠ Availability: The former is "who is qualified to use it," the latter is "whether the system can be used."

Information Asset Classification Standards

Level	English	Standard	Typical Example
Public	Public	Disclosure will not cause harm	Marketing materials on the company website, announced financial reports
Internal	Internal	Disclosure will not cause major damage, but not actively leaked	Internal company website operational procedure documents
Confidential	Confidential	Disclosure may damage the enterprise	Trade secrets, unannounced product R&D plans
Private	Private	Disclosure may damage others' privacy	Employee ID numbers, customer credit card numbers, etc.

Information Asset Classification Judgment Process

The "Will disclosure cause harm?" judgment on the flowchart assesses "whether leakage will cause concrete damage or compliance issues." The difference between "Public" and "Internal" is not the degree of harm, but "whether it is actively disclosed to the public": marketing materials are Public, while internal SOPs, even if leakage has little impact, are still Internal. In practice, whether something is classified as Public requires explicit approval from the asset owner; otherwise, it should default to Internal.

Government Data Classification

Taiwan's government classifies confidential data from high to low according to the "National Secret Protection Act": Absolute Secret → Top Secret → Secret. General official documents are distinguished as "Secret" or "General" according to the "Document Processing Manual." Similar to the enterprise four-level classification logic, the core difference is that government classification focuses on national security impact, while enterprise classification focuses on commercial damage.

After asset classification is determined, the next step is to clarify who is responsible for deciding the classification and who is responsible for implementing controls.

Asset Management Roles

Role	English	Typical Holder	Responsibility
Asset Owner	Asset Owner	Business Unit Manager	Decides classification level, approves access authorization, bears final security responsibility
Asset Custodian	Asset Custodian	IT Department	Implements technical measures such as storage, backup, and access control according to owner instructions, has no authority to adjust levels independently

Key Points for Asset Classification Judgment

Level adjustments (including upgrades and downgrades) must be decided by the Asset Owner according to organizational policies and risk assessment procedures and cannot be changed arbitrarily; downgrades must be documented in writing for auditing.
Personally Identifiable Information (ID card, credit card number) → Private; Trade secrets → Confidential.

Difference from Information Security Roles

Similar to the direction of Asset Management Owner/Custodian, but the legal framework is different and cannot be directly equated:

Data Controller vs Asset Owner: The legal responsibility of the Controller is defined by GDPR/PII laws, and violations can be penalized by competent authorities; the responsibility of the Asset Owner comes from internal organizational policies.
Data Processor vs Asset Custodian: A Data Processing Agreement (DPA) must be signed in writing between the Processor and the Controller; the relationship between the Custodian and the Owner is an internal division of duties and does not require external contracts.

Regulations and Compliance

ISO/IEC 27001 and ISMS Basic Requirements

ISO/IEC 27000 Series Standards

Standard	Topic	Certifiable?	Key Description
ISO/IEC 27000	Overview of terms and definitions	❌ Not certifiable	Defines terms and concepts used throughout the 27000 series, serving as the foundational dictionary for reading other standards
ISO/IEC 27001	Information Security Management System (ISMS) Requirements	✅ Can apply for third-party certification	Specifies the requirements that an organization must (SHALL) establish, implement, and maintain for an ISMS, and is the core of certification for the entire series
ISO/IEC 27002	Information Security Control Measures Guidelines	❌ Not certifiable	Provides implementation suggestions (SHOULD) for control measures in Annex A of 27001, serving as an operational manual rather than a specification
ISO/IEC 27003	ISMS Implementation Guidance	❌ Not certifiable	Explains how to implement 27001 clauses, providing implementation examples and recommended practices
ISO/IEC 27004	Information Security Measurement and Evaluation	❌ Not certifiable	Provides design methods for measurement indicators, corresponding to 27001 Clause 9 (Performance Evaluation), assisting organizations in evaluating ISMS effectiveness
ISO/IEC 27005	Information Security Risk Management	❌ Not certifiable	Provides guidance on the risk management process (Identification → Assessment → Treatment → Monitoring), providing a methodology for 27001 risk assessment
ISO/IEC 27006	Requirements for Certification Bodies	✅ (Applicable to certification bodies themselves)	Specifies the conditions that third-party bodies performing ISMS audits and certifications must meet; not applicable to general organizations
ISO/IEC 27007	ISMS Audit Guidance	❌ Not certifiable	Provides methodology for performing ISMS internal audits and third-party audits, supplementing ISO 19011 for information security audit scenarios
ISO/IEC 27017	Cloud Service Security Controls	Depends on certification body	Additional control guidance for cloud providers and tenants, supplementing 27002 for cloud scenarios
ISO/IEC 27018	Public Cloud PII Protection	Depends on certification body	Guidance for PII protection in cloud environments, consistent with the spirit of GDPR

ISO/IEC 27001 and SoA Key Points

27001 Clauses 4–10 are mandatory (SHALL), and organizations must meet all of them to obtain certification.
Passing 27001 certification = ISMS management system complies with the specification; 27002 is a reference manual for "recommended practices" and is not certifiable itself.
The 93 control measures in Annex A do not require full implementation; organizations select applicable items based on risk assessment results and record the reasons for selection or exclusion for each control in the Statement of Applicability (SoA).
27002 provides implementation suggestions (SHOULD) for each control measure; practices can differ from 27002, but must be explained in the SoA.
ISO only publishes standards and does not issue individual qualifications; Lead Auditor certificates are issued by personnel certification bodies (e.g., IRCA, PECB) in accordance with ISO/IEC 17024.

ISMS Core Elements

Element	English	Description	Specific Requirements
Context	Context	Understand organizational environment and stakeholder needs	Identify internal/external issues, regulatory requirements, stakeholder expectations
Leadership	Leadership	Commitment and participation of senior management	Establish security policy, assign security responsibilities, provide resources
Planning	Planning	Risk assessment and goal setting	Perform risk assessment, develop risk treatment plans, set measurable security goals
Support	Support	Provide necessary resources and capabilities	Manpower allocation, education and training, documented procedures, internal communication
Operation	Operation	Implement and run ISMS	Execute risk treatment measures, control measure operation, supplier management
Performance Evaluation	Performance Evaluation	Monitoring and measurement	Internal audit, management review, performance indicator monitoring
Improvement	Improvement	Continuous improvement mechanism	Handling non-conformities, corrective actions, preventive actions

ISO 27001 Annex A Control Measure Categories

Topic	English	Number of Controls	Scope
Organizational	Organizational	37	Security policy, roles and responsibilities, asset management, supplier relationships, incident management
People	People	8	Pre-employment screening, security awareness training, disciplinary procedures, termination procedures
Physical	Physical	14	Secure areas, equipment protection, cabling security, media disposal
Technological	Technological	34	Access control, encryption, network security, secure development, vulnerability management

Total of 93 control measures (the 2013 version had 114; after the 2022 revision, 11 were added and others were merged and streamlined).
New controls include: Threat Intelligence, Cloud Service Security, Data Masking, Monitoring Activities, etc.

ISMS Effectiveness Indicators

Indicator Type	Example Indicator	Target Value Reference
Preventive Effect	Security awareness training completion rate, vulnerability patching time	Training completion rate > 95%, high-risk vulnerability patching < 72 hours
Detection Capability	Mean Time to Detect (MTTD), false positive rate	MTTD < 24 hours, false positive rate < 5%
Response Efficiency	Mean Time to Respond (MTTR), incident resolution rate	MTTR < 4 hours, resolution rate > 98%
Compliance Degree	Audit finding improvement rate, control measure effectiveness	Major findings 100% improved, control effectiveness > 90%

ISMS PDCA Cycle

ISO/IEC 27001 adopts the PDCA cycle to ensure continuous improvement of the ISMS:

Stage	English	Core Task
Plan	Plan	Establish ISMS policy, goals, and risk assessment process, develop risk treatment plans
Do	Do	Implement and run ISMS policies, control measures, and procedures
Check	Check	Evaluate ISMS performance, perform internal audits and management reviews, report results to management
Act	Act	Take corrective and preventive actions based on audit results to promote continuous ISMS improvement

Audit Type (Three-Party) Comparison Table

Type	English	Description	Typical Example
First-party Audit	1st Party	Internal audit, organization performs on itself	Internal security audit performed by the company itself
Second-party Audit	2nd Party	Audit performed on external suppliers or partners; audit by competent authorities on subordinate agencies	Financial Supervisory Commission audits banks under its jurisdiction; customers audit suppliers
Third-party Audit	3rd Party	Performed by independent verification/certification bodies, can issue certification certificates	ISO 27001 certification audit

Judging Second-party vs Third-party Audits

Only third-party audits can issue external certification certificates (e.g., passing ISO 27001 certification).
Audits by competent authorities (e.g., Financial Supervisory Commission auditing banks) = Second-party, not third-party.
Common misconception: It feels like the competent authority is an "external independent third party," but in ISO definitions, external parties with a vested interest (regulatory agencies, customers) are all considered second-party.

Third-party Audit Certification Comparison Table

Certification / Report	Nature	Audit Scope	Features
SOC 2 Type 1	Third-party audit report	Whether system design at a specific point in time meets Trust Services Criteria (TSC)	Point-in-time, only proves design is reasonable, does not verify actual operational effectiveness
SOC 2 Type 2	Third-party audit report	Whether system operation over a period of time (usually 6–12 months) meets TSC	Period-of-time, verifies control measures are continuously and effectively operating; more persuasive than Type 1
ISO 27001 Certificate	Third-party certification	Whether ISMS management system meets ISO 27001 standard	Annual surveillance audit + recertification every three years; focuses on "management system" rather than technical control operational details
PCI DSS AoC	Attestation of Compliance	Whether Payment Card Industry Data Security Standard (PCI DSS) requirements are met in the Cardholder Data Environment (CDE)	Applicable to organizations handling credit card transactions, requirements vary greatly by level (Level 1 requires on-site audit by QSA)

SOC 2 Type 1 vs Type 2

Type 1 = Blueprint Review: Control measures are reasonably designed, but it has not been verified whether they are actually being executed.
Type 2 = Actual Acceptance: During an observation period, control measures are indeed effectively operating.
Mainstream cloud service providers (e.g., AWS, Azure, GCP) generally continuously produce SOC 2 Type 2 reports for enterprise customers to use in supplier risk assessments.

NIST CSF and NIST SP 800 Series

NIST CSF (Cybersecurity Framework)

A voluntary cybersecurity framework released by the US NIST (National Institute of Standards and Technology), widely applied across industries. CSF 2.0 (released in 2024) added the Govern function, emphasizing the governance level, defining six core functions, and providing a structured method for organizations to assess and improve their security posture.

Function	English	Description	Corresponding Activities
Govern	Govern (GV)	Establish security governance structure and strategy to ensure security risk management aligns with organizational goals (Added in CSF 2.0)	Security policy formulation, role and responsibility assignment, supply chain risk management
Identify	Identify (ID)	Inventory organizational assets, business environment, and risks	Asset management, risk assessment, supply chain identification
Protect	Protect (PR)	Implement control measures to protect critical assets	Access control, data security, security awareness training, platform security
Detect	Detect (DE)	Timely discovery of security incidents	Continuous monitoring, anomaly analysis, incident detection procedures
Respond	Respond (RS)	Take action on confirmed incidents	Incident management, analysis, notification, corrective actions
Recover	Recover (RC)	Restore affected services to normal	Recovery plan execution, improvement measures, external communication

NIST CSF vs ISO 27001

NIST CSF: Voluntary framework, no certification system, focuses on "what to do" (function-oriented), suitable as a starting point for security maturity assessment.
ISO 27001: Can apply for third-party certification, focuses on "how to manage" (management system-oriented), suitable for organizations that need to prove compliance externally.
The two are complementary: Organizations can use NIST CSF to assess the gap between current status and goals, and then use ISO 27001 to establish a certifiable management system.
CSF 2.0 added the "Govern" function, emphasizing that security governance should be led by senior management, which is consistent with the spirit of ISO 27001 management review.

NIST SP 800 Series

A series of Special Publications released by NIST, covering technical guidance and control specifications for various security topics, primarily for US federal agencies as a basis for FISMA compliance, but also widely referenced by non-federal organizations.

Document	Topic	Key Description
SP 800-37	Risk Management Framework (RMF)	Defines a seven-step risk management process (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor), the primary compliance basis for federal agencies
SP 800-53	Security and Privacy Controls	Hundreds of control measures classified into 20 control families (e.g., AC Access Control, IR Incident Response), the implementation basis for SP 800-37
SP 800-61	Computer Security Incident Handling Guide	(Rev. 3, 2025) Incorporates incident response into the overall risk management context of CSF 2.0, with IR activities spanning all six Functions (Govern, Identify, Protect, Detect, Respond, Recover)
SP 800-63	Digital Identity Guidelines	Specifies Authenticator Assurance Levels (AAL), Identity Assurance Levels (IAL), and Federation Assurance Levels (FAL)
SP 800-88	Guidelines for Media Sanitization	(Rev. 2, 2025) Divides media sanitization into three levels: Clear / Purge / Destroy, providing a decision framework for choosing sanitization methods based on data sensitivity and device type
SP 800-171	Protecting CUI	Security requirements for non-federal systems processing Controlled Unclassified Information (CUI), commonly used for government supply chain compliance
SP 800-207	Zero Trust Architecture	Defines seven Zero Trust Tenets and the PE/PA/PEP logical architecture components, providing a reference architecture for federal agencies to migrate to Zero Trust

NIST CSF vs SP 800 Series

CSF: Defines "what results to achieve" (high-level function-oriented), suitable for assessing and communicating security posture.
SP 800 Series: Defines "what specific controls and processes to implement" (detailed technical-oriented), suitable for federal compliance and detailed implementation planning.
The two are complementary: CSF is the map, and the SP 800 series is the construction specification for each region.

COBIT Governance Framework

COBIT (Control Objectives for Information and Related Technologies)

An IT governance framework released by ISACA, currently in version COBIT 2019. The core question is "Is IT doing the right things, and doing them compliantly?", aimed at management and auditors.

COBIT divides IT activities into two levels:

Level	English	Description
Governance	Governance	Set direction, evaluate options, monitor execution, responsible by the board or senior management
Management	Management	Plan, build, execute, monitor specific activities, responsible by IT management

Common use cases: IT auditing, SOX compliance (Sarbanes-Oxley Act), and combined with ISO 27001 as a reference for the governance layer.

ITIL Service Management Framework

ITIL (Information Technology Infrastructure Library)

An IT service management framework released by PeopleCert (formerly AXELOS), currently in version ITIL 4 (2019). The core question is "Is IT delivering services well and operating stably?", aimed at IT operations and service management teams.

ITIL 4 centers on the Service Value System (SVS), containing 34 management practices, divided into three categories by function:

Category	Description	Representative Practices
General Management Practices	Management activities common across the organization	Risk management, information security management, knowledge management
Service Management Practices	Management activities specific to IT services	Incident management, problem management, change enablement, service desk
Technical Management Practices	Technology-oriented management activities	Infrastructure management, deployment management

Intersection with security: Incident Management, Problem Management, Change Enablement (called Change Control in ITIL v3) processes overlap heavily with security incident handling and vulnerability patching processes.

COBIT vs ITIL

COBIT: IT governance framework, answers "Are we doing the right things?", aimed at management and auditors.
ITIL: IT service management framework, answers "Are we doing services well?", aimed at operations teams.
The two are parallel, with no hierarchical relationship. In practice, they can be used together: COBIT sets governance goals, and ITIL implements service processes.

Aspect	GDPR (EU)	Taiwan Personal Data Protection Act
Applicability	Organizations processing PII of EU residents (no geographical limit, applies to Taiwan enterprises serving EU users)	Public and non-public agencies collecting, processing, or using PII within Taiwan
PII Definition	Any information that can directly or indirectly identify a natural person	Name, date of birth, ID number, etc., that can directly or indirectly identify an individual
Core Principles	Lawfulness, fairness, transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality	Legitimate purpose, necessity principle, data subject consent (written consent as a principle)
Data Subject Rights	Access, rectification, erasure (right to be forgotten), portability, object to processing, restriction of processing	Query, review, copy, supplement, correct, stop collection/processing/use, delete
Data Breach Notification	Notify competent authority (DPA) within 72 hours	No unified statutory time limit, notify as soon as possible according to competent authority requirements
Maximum Penalty	€20,000,000 or 4% of global annual turnover (whichever is higher)	Non-public agencies: Fine of up to NT$15 million
Data Protection Officer (DPO)	Mandatory in specific cases	No mandatory requirement
Cross-border Transfer	Must ensure adequate protection level in the receiving country (e.g., SCCs Standard Contractual Clauses, adequacy decision)	Must be based on specific purposes and protected by the laws of the receiving country, or obtain data subject consent

TIP

Extraterritorial effect of GDPR: The trigger condition is not "where the organization is," but "whether it actively provides services to EU residents or monitors their behavior" (GDPR Art. 3(2)). Practical judgment criteria include: whether local EU languages are provided, whether Euro payments are accepted, whether the EU market is explicitly mentioned in marketing, etc. If the service has no geographical identification mechanism and treats all regions equally, it depends on whether there is an "intent to actively reach EU users," not automatically applicable just because there are EU users.
"Right to be forgotten" and "Right to data portability" are the most obvious differences between GDPR and Taiwan's PII Act.
GDPR penalties are far higher than Taiwan's PII Act, so for enterprises with large operations in the EU, GDPR compliance usually has a higher priority.

Taiwan PII Act: Notification Obligation (Articles 8, 9)

The timing of notification when collecting PII depends on the collection method:

Collection Method	Article	Notification Timing
Direct Collection (obtained from the data subject, e.g., filling out a form)	Article 8	At the time of collection
Indirect Collection (obtained from someone other than the data subject, e.g., from a third party)	Article 9	At the time of first use of the PII

The notification content is the same for both cases: name of the collecting agency, purpose of collection, PII category, period/region/object/method of use, and rights that the data subject can exercise.

Advanced Privacy Concepts

Data Sovereignty: Data is subject to the laws of the country where it is stored. When an organization uses cloud services, if data is stored on servers in other countries, it may be subject to the laws of multiple countries simultaneously (e.g., the US CLOUD Act allows the US government to cross-border access data held by US companies).

DPIA (Data Protection Impact Assessment): GDPR Article 35 requires prior impact assessment for high-risk PII processing activities to identify privacy risks and develop mitigation measures. Although Taiwan's PII Act has no explicit DPIA article, competent authorities encourage organizations to conduct them voluntarily.

Data Minimization and Purpose Limitation

These are two core concepts among the eight GDPR principles most often related to "collecting PII":

Principle	English	Definition	Common Violation Case
Data Minimization	Data Minimization	Collect only the PII necessary to achieve a specific purpose; do not collect more or excessively	Requiring ID number, occupation, annual income, etc., unrelated to the service when applying for membership
Purpose Limitation	Purpose Limitation	PII can only be used for the purpose stated at the time of original collection; it cannot be used for other purposes	Phone numbers collected for "customer service needs" are used for marketing SMS

The two are complementary: Purpose limitation determines "where it can be used," and data minimization determines "how much can be collected."
Violating purpose limitation is usually more serious than violating data minimization because if data already collected is misused, it is difficult for the data subject to remedy.

PII Processing Roles

Role	English	Typical Holder	Responsibility
Data Controller	Data Controller	Enterprise or agency collecting PII	Decides the purpose and processing method of PII, bears primary legal responsibility externally
Data Processor	Data Processor	Entrusted third-party vendor	Executes PII processing according to Controller instructions, must sign a Data Processing Agreement (DPA)

HIPAA Medical Data Protection Regulation

HIPAA (Health Insurance Portability and Accountability Act)

A US federal regulation from 1996 that mandates privacy and security protections for Protected Health Information (PHI) in the healthcare industry. Applicable entities fall into two categories:

Covered Entities: Healthcare providers, health insurance companies, health information exchange organizations.
Business Associates: Third-party vendors entrusted by Covered Entities to process PHI (e.g., cloud storage, billing system operators).

Rule	English	Core Requirement
Privacy Rule	Privacy Rule	Limits the scope of PHI use and disclosure, patient authorization must be obtained; grants patients the right to access and correct their own data
Security Rule	Security Rule	Mandates three types of protective measures for electronic PHI (ePHI): administrative (policies/procedures), physical (facility access control), and technical (encryption/access control)
Breach Notification Rule	Breach Notification Rule	ePHI breaches must be notified to affected individuals and HHS within 60 days; single incidents involving 500 or more people must be notified to local media simultaneously

💡 Terminology Quick Check

PHI: Protected Health Information
ePHI: Electronic Protected Health Information
HHS: Department of Health and Human Services
HIPAA vs GDPR: HIPAA applies only to the healthcare industry and is a US regulation; GDPR applies across industries and covers all PII processing within the EU.

Major Frameworks and Regulations Quick Check

Framework/Regulation	Nature	Focus	Applicable Entities	Mandatory?
ISO 27001	Management System Standard	Information Security Management (ISMS)	Universal (all industries)	Voluntary (can apply for certification)
NIST CSF	Security Framework	Security Risk Management (Six Functions)	Universal (US government priority)	Voluntary
NIST SP 800 Series	Technical Guidance and Control Specs	Detailed implementation of various security topics (including 800-53 controls)	US federal agencies (non-federal can reference)	Mandatory for federal agencies
COBIT	Governance Framework	IT Governance and Control Objectives	IT governance layer, auditors	Voluntary (often used as audit benchmark)
ITIL	Service Management Framework	IT Service Delivery and Operations	IT operations/service management teams	Voluntary
GDPR	Regulation	Personal Data Protection	Organizations processing PII of EU residents	Mandatory
Taiwan PII Act	Regulation	Personal Data Protection	Agencies and enterprises collecting/processing PII within Taiwan	Mandatory
HIPAA	Regulation	Medical Health Information Protection	US healthcare industry	Mandatory
PCI DSS	Industry Standard	Credit Card Transaction Data Security	Organizations handling credit card transactions	Mandatory (required by card organizations)

ISO 27001 vs NIST CSF: 27001 has a third-party certification system; CSF has no certification and focuses on maturity assessment.

Information Security Responsibility Level Operations Requirements Table (A to E Levels)

Responsibility levels decrease from A to E, with Level A being the most stringent and Level E the most lenient.

Item / Responsibility Level	Level A	Level B	Level C	Level D	Level E
Dedicated Security Personnel	4+	2+	1+	0 (concurrently held by IT staff)	0 (concurrently held by general staff)
ISMS Certification	Entire agency mandatory third-party verification	Core systems should pass third-party verification	Core systems should pass third-party verification	Self-handled according to competent authority regulations	Self-handled according to competent authority regulations
SOC (Security Operations Center) Monitoring	Must be built, 24/7 uninterrupted monitoring for the entire agency	Must be built for core systems	Can be built based on agency scale and risk needs	None	None
Vulnerability Scanning	Once a year (entire agency)	Once a year (core systems)	Once a year (core systems)	Once every 2 years	None
Penetration Testing	Once every 2 years	Once every 2 years	Once every 2 years	None	None
Security Health Check	Once a year	Once a year	Once every 2 years	None	None
Security Training (hours/year)	Dedicated personnel: 12 hours	Dedicated personnel: 12 hours	Dedicated personnel: 12 hours	Concurrent IT personnel: 3 hours	General concurrent staff: 3 hours

TIP

A vs B: The difference in ISMS certification and SOC monitoring is the scope; Level A covers the entire agency, while Level B only targets core systems.
Level C is the watershed: The minimum threshold for penetration testing and security health checks; neither exists from Level D onwards.
Level D onwards switches to concurrent system: No dedicated security personnel, concurrently held by IT staff, vulnerability scanning reduced to once every 2 years.
E vs D: Vulnerability scanning is still once every 2 years at Level D, and only completely canceled at Level E; concurrent personnel also downgraded from IT staff to general staff.

Risk Management

Differences between Vulnerability, Threat, and Risk

Term	English	Description	Analogy
Vulnerability	Vulnerability	A flaw in a system or process that can be exploited	The door lock is broken
Threat	Threat	An event or actor that could exploit a vulnerability to cause damage	A thief is active in the area
Risk	Risk	The likelihood and impact of a threat exploiting a vulnerability	The probability and loss of being breached

Risk = Threat × Vulnerability × Asset Value. If any factor is zero, the risk does not exist; if any factor is reduced, the overall risk decreases accordingly.

Risk Assessment and Treatment Detailed Process

Stage	Input	Activity	Output
Asset Identification	Organizational structure, business processes	Inventory and classify information assets	Asset inventory, asset value
Threat/Vulnerability Identification	Asset inventory, threat intelligence	Identify applicable threats and existing vulnerabilities	Threat list, vulnerability list
Risk Analysis	Threats, vulnerabilities, existing controls	Assess risk likelihood and impact	Inherent risk, residual risk
Risk Assessment	Risk value, risk appetite	Determine risk acceptability	Risk level, treatment priority
Risk Treatment	Unacceptable risks	Select and implement treatment measures	Risk treatment plan, control measures

Risk Analysis Method Comparison

Aspect	Qualitative Analysis	Semi-Quantitative Analysis	Quantitative Analysis
Output Format	Level description (e.g., High/Medium/Low, Risk Matrix)	Relative score (Likelihood score × Impact score)	Financial value (e.g., ALE = 120k/year)
Data Requirement	Expert judgment, questionnaires, interviews	Expert judgment + rating scale	Historical event data, statistical models
Analysis Difficulty	Lower	Medium	Higher, requires statistical and financial analysis skills
Subjectivity	High (depends on assessor experience)	Medium (mapping levels still has subjectivity)	Low (calculated based on data)
Typical Method	Risk Matrix (Likelihood × Impact), Delphi Method	Score Matrix (High=5, Medium=3, Low=1 multiplied for ranking)	ALE formula, Monte Carlo Simulation, FAIR model
Applicable Scenario	Preliminary screening, rapid classification when resources are limited	Lacks historical data but needs cross-project ranking comparison	When financial decision basis is needed (e.g., ROSI analysis)

Combining Qualitative and Quantitative Analysis

In practice, qualitative analysis is often used to quickly screen high-risk items, and then quantitative analysis is performed on these items to produce financial data. Pure quantitative analysis is uncommon because it is difficult to obtain reliable historical occurrence rate data for many risks.

Risk Matrix

Presents Likelihood and Impact in a two-dimensional matrix; the intersection determines the risk level, assisting in prioritizing treatment. It is a qualitative tool, outputting level labels, and does not involve financial values.

Likelihood ↓ / Impact →	Low	Medium	High
High	Medium	High	High
Medium	Low	Medium	High
Low	Low	Low	Medium

Delphi Expert Assessment Method

A structured expert consensus method used for risk assessment scenarios that lack historical data and must rely on expert judgment.

Send anonymous questionnaires to experts to collect individual opinions.
Summarize statistics and provide feedback to all experts.
Experts revise their own judgments based on group feedback.
Repeat iterations until opinions converge to a consensus.

The anonymous design aims to eliminate bandwagon effects and authority influence, ensuring each expert's judgment is independent.

Score Matrix Method

A semi-quantitative analysis tool that maps qualitative levels to organization-defined numerical values and multiplies them to produce a risk priority score. A common example is High=5, Medium=3, Low=1, but both the values and the number of levels can be adjusted according to needs; the scale must remain consistent within the same assessment.

Risk Priority = Likelihood Score × Impact Score, the result is only for relative ranking and does not represent the actual loss amount.

Risk Matrix vs Score Matrix

Both structures are the same (Likelihood × Impact), the difference is in the output format:

Risk Matrix (Qualitative): Outputs level labels (High/Medium/Low), used for rapid classification
Score Matrix (Semi-quantitative): Outputs numerical scores, used for cross-project priority comparison

Risk Quantification Formula

Term	Chinese	Description
ALE (Annualized Loss Expectancy)	Annualized Loss Expectancy	Average expected loss amount due to a specific threat within one year, $A L E = A R O \times S L E$
ARO (Annualized Rate of Occurrence)	Annualized Rate of Occurrence	Expected number of times a threat event occurs within one year (e.g., 0.1 = once every 10 years)
SLE (Single Loss Expectancy)	Single Loss Expectancy	Expected loss amount each time a threat event occurs, $S L E = A V \times E F$
AV (Asset Value)	Asset Value	Monetary value of the asset
EF (Exposure Factor)	Exposure Factor	Percentage of asset loss when a threat occurs (0–100%)

Formula Connection

$A L E = A R O \times S L E$

$S L E = A V \times E F$

$∴ A L E = A R O \times A V \times E F$

Example: Server value 1 million (AV), estimated loss of 60% after being encrypted by ransomware (EF = 0.6), estimated occurrence once every 5 years (ARO = 0.2). → SLE = 1 million × 0.6 = 600,000 → ALE = 0.2 × 600,000 = 120,000/year

If the annual cost of protective measures is less than 120,000, it is cost-effective.

Monte Carlo Simulation and ALE

The traditional ALE formula assumes ARO and EF are fixed values, but in reality, these parameters have uncertainty ranges (e.g., "occurs every 3–7 years"). Monte Carlo simulation performs massive random sampling, taking possible values for each variable, executing tens of thousands of calculations, and producing a probability distribution of ALE rather than a single number, which is the standard method for advanced Quantitative Risk Analysis (QRA).

For example, the output: "There is a 90% probability that the annualized loss will not exceed 500,000," which is more valuable for decision-making than "expected loss of 200,000."

ROSI (Return on Security Investment)

ROSI measures the financial rationality of security control measures: how much loss can the investment save?

R O S I = \frac{(A L E_{b e f o r e} - A L E_{a f t e r}) - Annual Cost of Control Measure}{Annual Cost of Control Measure} \times 100 %

Term	Description
ALE_before	Annualized Loss Expectancy before implementing control measures
ALE_after	Annualized Loss Expectancy after implementing control measures (after risk reduction)
Annual Cost of Control Measure	Total cost of ownership of the security measure per year (license fees + manpower + maintenance)

Example: Antivirus software annual fee 20,000, expected to reduce ALE from 150,000 to 30,000.

Loss saved: 150,000 − 30,000 = 120,000
Net benefit: 120,000 − 20,000 = 100,000
ROSI = 100,000 / 20,000 × 100% = 500% (every 1 unit invested saves 5 units of loss)

FAIR Model (Factor Analysis of Information Risk)

FAIR is the industry-mainstream quantitative risk analysis framework, an open standard maintained by The Open Group, which decomposes risk into a quantifiable factor tree structure, ultimately producing a probability distribution of loss.

Term	Description
Loss Event Frequency (LEF)	Expected number of times a threat successfully results in loss within a certain time
Threat Event Frequency (TEF)	Frequency of threat attempts (regardless of success or failure)
Vulnerability	Probability that a threat event converts into a loss event (the stronger the control measure, the lower this value)
Loss Magnitude	Impact scale of a single loss event, decomposed into primary loss and secondary loss (e.g., reputation damage, legal litigation)

FAIR vs Traditional ALE

The ALE formula is a "point estimate," while FAIR produces a conclusion of "X% probability that loss will not exceed Y amount" through factor decomposition and probability distribution, leading to higher decision quality.
FAIR and ISO 27005, NIST CSF can be used complementarily: ISO 27005 defines the risk management process, and FAIR provides quantitative analysis methods.
Implementation threshold: Requires collecting fine-grained threat and control measure data, suitable for organizations with higher security maturity.

Risk Treatment Strategy Comparison Table

Strategy (ISO 27005)	English	Definition	Example	Applicable Scenario
Risk Avoidance	Risk Avoidance	Abandon activities or assets that may trigger risk	Stop using insecure legacy protocols, abandon high-risk markets	Risk is too high and cannot be effectively reduced
Risk Modification	Risk Modification	Implement control measures to reduce risk likelihood or impact	Deploy firewall, implement MFA, encrypt transmission	Risk is within acceptable range, and control measure cost is reasonable
Risk Sharing	Risk Sharing	Share part of the consequences of risk with third parties, usually part of financial impact or contractual liability	Purchase cyber insurance, outsourcing (MSP/MSSP), SLA agreed compensation mechanism	Risk impact is large, but impact can be dispersed through contracts or insurance
Risk Retention	Risk Retention	Acknowledge risk exists, take no additional measures	Residual risk is below risk appetite, patching cost far exceeds potential loss	Risk is within tolerable range, or control cost is not cost-effective

ISO 27005 Risk Treatment Process

Risk Assessment: Identification → Analysis → Evaluation.
Based on assessment results, select treatment strategies (Avoidance/Modification/Sharing/Retention) for each risk.
Develop a Risk Treatment Plan, recording selected strategies and implementation schedules.
Residual Risk must be formally approved for acceptance by management.

Risk Terminology Supplementary Comparison Table

Term	English	Definition
Inherent Risk	Inherent Risk	Risk level before implementing any control measures, reflecting the natural exposure of assets to threats
Residual Risk	Residual Risk	Remaining risk after implementing risk treatment measures, must be formally accepted by management
Secondary Risk	Secondary Risk	New risks triggered by the risk response measures themselves (e.g., introducing monitoring systems to reduce security incident risk, but simultaneously creating employee privacy concerns)
Risk Transfer	Risk Transfer	Transferring specific parts of risk consequences to third parties through insurance, contracts, or compensation clauses
Risk Acceptance	Risk Acceptance	Management is aware of and formally accepts risk, takes no further treatment measures, applicable when residual risk is within risk appetite
Risk Capacity	Risk Capacity	The maximum loss limit an organization can bear without jeopardizing survival, an objective financial/operational boundary (different from risk appetite: the latter is subjective willingness, the former is objective capability)
Risk Appetite	Risk Appetite	The upper limit of risk an organization strategically chooses to actively bear, a subjective willingness decision, must be lower than or equal to risk capacity
Risk Threshold	Risk Threshold	Trigger level for specific risks, requires immediate response when exceeded, usually lower than risk appetite

Risk Sharing vs Risk Transfer

Comparison	Risk Sharing	Risk Transfer
ISO 27005 Term	✅ Official term	Common colloquialism, not an official ISO 27005 term
Definition	Share risk consequences with third parties, usually part of financial loss, service level breach liability, or operational impact	Transferring specific risk consequences to third parties through insurance or contracts, usually emphasizing the transfer of "financial burden"
Substantive Difference	Original risk and governance responsibility remain with the organization, only shared consequences with third parties	Semantically stronger, but in practice usually only transfers part of financial consequences, does not mean legal responsibility disappears completely
Example	Outsourcing: Service interruption loss shared by both parties according to SLA or compensation cap	Purchase cyber insurance: Insurance company absorbs part of the claim amount

The two are often used interchangeably in practice; ISO/IEC 27005 officially adopts Risk Sharing, while Risk Transfer is a more common colloquialism. Regardless of the term used, insurance or outsourcing contracts can only transfer part of the financial consequences; compliance obligations and legal responsibilities under GDPR, PII Act, etc., do not disappear because of this.

Risk Retention vs Risk Acceptance

Comparison	Risk Retention	Risk Acceptance
Nature	Risk treatment strategy (one of four)	Formal approval action by management
Source	ISO 27005 treatment option list; ISO 27001 text does not list strategy names	ISO 27001 Clause 6.1.3e directly requires; ISO 27005 explains process details
Timing	After assessment, choose not to take additional control measures	After any treatment strategy is executed, formal sign-off on residual risk
Relationship	Can be established independently	Must have corresponding risk acceptance after every treatment strategy is executed

The two can be established simultaneously: Choose "Risk Retention" (no treatment) → Residual risk equals inherent risk → Management executes "Risk Acceptance" for formal approval.

Hierarchical Relationship of Risk Appetite, Risk Capacity, and Risk Threshold

Risk Capacity: Objective upper limit, organization cannot survive if exceeded (e.g., total loss of net assets).
Risk Appetite: Subjective willingness, how much risk the organization strategically chooses to bear, must be ≤ Risk Capacity.
Risk Threshold: Trigger level for specific risks, requires immediate response when exceeded, usually lower than risk appetite.

Hierarchical order from high to low: Risk Capacity ≥ Risk Appetite ≥ Risk Threshold.

Relationship between Inherent Risk and Residual Risk

No control measure can reduce risk to zero; residual risk must be formally accepted by management.
Secondary risk is a link often overlooked in risk management plans: when assessing response measures, it is necessary to simultaneously identify whether new risks are introduced.

Shadow IT

Definition: Software, cloud services, or hardware devices adopted by employees or teams without approval from the IT department. Shadow IT is like an "underground market" in the office: employees bypass formal IT procurement to meet deadlines, buying SaaS with private accounts, opening cloud resources, or even pasting data into AI assistants. With the popularity of SaaS tools and the rise of AI services, the scope of Shadow IT has expanded significantly.

Common Types:

Type	Description	Typical Example
Shadow SaaS	Employees privately use unapproved SaaS tools	Personal Google Drive, Dropbox, Notion
Shadow Cloud	Engineers open cloud resources with personal or credit card accounts, bypassing IT procurement processes	Self-built AWS accounts, Azure subscriptions
Shadow AI	Employees input company data into unapproved AI tools	Pasting customer data or source code into ChatGPT, using unvetted AI Coding Assistants
Shadow Data	Data is copied to unmanaged storage locations, forming untracked data copies	Exporting databases to personal NAS, forwarding email attachments to personal mailboxes
Shadow Hardware	Physical devices not registered with IT connected to the enterprise network	Personal NAS, Raspberry Pi, undeclared routers

Common Risks:

Risk	Description
Data Leakage	Sensitive data enters unmanaged services; supplier terms may allow using data to train models (Shadow AI is particularly obvious)
Compliance Violation	Data storage locations may violate data sovereignty or GDPR regulations
Lack of Patch Management	Software not included in enterprise patching processes may have known vulnerabilities
Audit Blind Spot	Unable to track data flow and usage records, difficult to trace after an incident

Countermeasures: CASB to detect unauthorized cloud services, SaaS management platforms, regular cloud usage inventory; provide approved alternatives to reduce employee motivation to bypass (employees often use Shadow IT because official tools are inefficient).
Intersection of Shadow IT and BYOD: Employees install unapproved work applications on personal devices, touching both issues simultaneously.

Incident Management

Information Security Incident Classification

Classification	English	Description	Example	Response Priority
Security Event	Security Event	State change identified in system or network	Firewall log denies connection	Low (record only)
Security Alert	Security Alert	Notification that may indicate a security event	IDS detects abnormal traffic	Medium (needs analysis)
Security Incident	Security Incident	Confirmed violation of security policy or threat	Malware infection, data leakage	High (immediate response)
Major Security Incident	Major Incident	Incident causing major impact on business operations	Ransomware locking core systems	Highest (crisis management)

Inclusion Relationship of the Four

All incidents are events, but not all events are incidents. The four have a nested inclusion relationship, not a parallel classification:

Event ⊃ Alert ⊃ Incident ⊃ Major Incident

Event: Broadest scope, any observable system state change is an event, including massive normal logs.
Alert: Filtered from events as notifications requiring attention, still possibly a False Positive.
Incident: Confirmed violation of security policy after analysis, upgraded to incident, requiring formal response.
Major Incident: A subset of incidents affecting business operations, requiring the initiation of crisis management processes.

Information Security Incident Severity Classification Comparison Table (Levels 1 to 4)

The higher the number, the more severe the information security incident.

Item / Severity Level	Level 1	Level 2	Level 3	Level 4
Judgment Criteria (Core Logic)	Non-core system interruption, no PII or confidential data leakage	Non-core system paralysis, or involvement of general PII leakage	Core system paralysis, data tampering, or sensitive PII leakage	National security threatened, critical infrastructure large-scale shutdown
Notification Time Limit	Within 1 hour	Within 1 hour	Within 1 hour	Within 1 hour
Damage Control or Recovery Operations	Within 72 hours	Within 72 hours	Within 36 hours	Within 36 hours
Investigation, Handling, and Improvement Report Submission Deadline	Within 1 month	Within 1 month	Within 1 month	Within 1 month
Typical Example	Official website graffiti, general office computer virus infection	Core business briefly interrupted, general PII leakage	Medical record leakage, official document leakage, core system crash	Power grid/water conservancy paralysis, military or diplomatic secret leakage

Taiwan Regulation Time Limit Supplement

According to the current "Regulations on Notification, Response, and Drills for Information Security Incidents," after completing damage control or recovery for incidents of all levels, investigation and handling should continue, and an investigation, handling, and improvement report should be submitted within 1 month.

Information Security Incident Response (NIST SP 800-61)

NIST SP 800-61 Rev. 3 (April 2025) positions incident response as a component of CSF 2.0 risk management, no longer presented as an independent "Incident Handling Manual." IR activities span all six Functions of CSF 2.0, with Govern and Identify as the governance foundation, Protect responsible for preparation and defense, Detect, Respond, and Recover responsible for actual incident handling; continuous improvement spans the entire IR lifecycle, no longer occurring only after the fact.

Chinese Name	CSF 2.0 Function	Core Task
Governance	Govern	Establish IR policy, role assignment, authorization, and resource allocation
Identification	Identify	Identify critical assets, assess threat scenarios, establish IR trigger conditions
Protection	Protect	Deploy detection tools, establish CSIRT, develop response plans and drills
Detection	Detect	Identify incidents through SIEM, IDS, and log monitoring, determine severity and impact scope
Response	Respond	Contain affected systems, remove malware and vulnerabilities, execute communication and coordination
Recovery	Recover	Restore systems and verify normal operation, write incident reports, update response plans

Rev. 2 (2012) Four-Stage Lifecycle

Rev. 2 (revoked in April 2025) defined the incident handling lifecycle in four stages:

Stage	Chinese Name	English Name	Core Task
1	Preparation	Preparation	Establish CSIRT, develop response plans, deploy detection tools, conduct education, training, and drills
2	Detection and Analysis	Detection & Analysis	Identify incidents through SIEM, IDS, and log monitoring, determine incident severity and impact scope
3	Containment, Eradication, and Recovery	Containment, Eradication & Recovery	Isolate affected systems (containment) → remove malware and vulnerabilities (eradication) → restore systems and verify normal operation (recovery)
4	Post-Incident Activity	Post-Incident Activity	Write incident reports, review improvement measures, update response plans, preserve evidence (for legal or audit purposes)

💡 Terminology Quick Check

CSIRT: Computer Security Incident Response Team
SIEM: Security Information and Event Management
IDS: Intrusion Detection System

Incident Handling Priority

Containment is the first priority: isolate infected systems first to prevent disaster expansion, then perform eradication and recovery.
"Lessons Learned" in post-incident activities is key to continuous improvement; every incident should produce improvement suggestions fed back to the preparation stage.

Differences between CSIRT, CERT, and SOC

Organization	Full Name	Positioning	Scope of Responsibility
CSIRT	Computer Security Incident Response Team	Incident response team	Internal security incident detection, analysis, containment, and recovery, can be permanent or temporary
CERT	Computer Emergency Response Team	Emergency response center	National or regional level, provides cross-organizational security incident coordination and early warning (e.g., TWCERT/CC)
SOC	Security Operations Center	Security operations center	24/7 continuous monitoring, handles daily alerts and incident classification, CSIRT handles incidents escalated by SOC

CERT often acts as a national-level coordination center (e.g., Taiwan's TWCERT/CC, US-CERT), while CSIRT tends to be an internal organizational team.
SOC focuses on daily monitoring and initial alert screening, while CSIRT focuses on in-depth incident investigation and response. The two often work together: SOC detection → escalation to CSIRT handling.

MTTD / MTTA / MTTR Incident Response Indicators

Indicator	Full Name	Definition	Calculation Method
MTTD	Mean Time To Detect	Average time from actual threat occurrence to incident detection	Detection time − Incident occurrence time
MTTA	Mean Time To Acknowledge	Average time from alert trigger to analyst confirmation of takeover	Takeover time − Alert trigger time
MTTR	Mean Time To Respond	Average time from incident detection to completion of response (containment/eradication/recovery)	Response completion time − Detection time

Timeline order: Threat occurrence → MTTD → Detection confirmation/Alert trigger → MTTA → Analyst takeover → MTTR → Resolution

Shortening MTTD is more critical than shortening MTTR: The longer an attacker lurks inside the organization (Dwell Time), the greater the scope of lateral movement and data theft.
Industry reference: Industry data shows that the global average Dwell Time has shortened from hundreds of days to about 10 days, but there is still room for improvement.
Practices to improve MTTD: SIEM correlation analysis, EDR (Endpoint Detection and Response), Threat Hunting.
Definition in these notes: MTTR start point is detection time, so MTTR covers MTTA (MTTA is a sub-interval of MTTR).
Another common definition: Some organizations define the MTTR start point as analyst takeover time, in which case MTTA and MTTR are non-overlapping continuous intervals, total response time = MTTA + MTTR.
Relationship with MTTP: MTTD/MTTA/MTTR are response indicators "after an incident occurs"; vulnerability management has another MTTP (Mean Time To Patch), measuring the average time from "vulnerability disclosure to completion of patching," which belongs to the pre-incident prevention stage KPI.

Post-Incident Report

Element	Description
Incident Timeline	Complete record of every time node from detection, notification, containment to recovery
Root Cause Analysis	Trace the root cause of the incident, rather than just describing surface symptoms
Impact Scope	Affected systems, number of data records, business interruption time
Corrective Actions	Actions already taken (e.g., patching vulnerabilities, blocking accounts, updating rules)
Preventive Recommendations	Long-term improvement measures to prevent recurrence of similar incidents

Cross-Platform Log Management and Forensics Path

Aspect	Windows	Linux
System Logs	Event Viewer: `Application`, `Security`, `System` channels	`/var/log/syslog` (Debian family) or `/var/log/messages` (RHEL family); systemd uses `journalctl`
Security/Auth Logs	`Security` event records (Logon success 4624, Logon failure 4625, Account creation 4720)	`/var/log/auth.log` (Debian) or `/var/log/secure` (RHEL)
Web Server Logs	IIS: `C:\inetpub\logs\LogFiles\`	Apache: `/var/log/apache2/`; Nginx: `/var/log/nginx/`
Firewall Logs	Windows Firewall: Event Viewer `Windows Firewall With Advanced Security`	`iptables`: `/var/log/kern.log`; `nftables`: `journalctl -k`
Centralized Management	Windows Event Forwarding (WEF)	rsyslog / syslog-ng remote forwarding to SIEM
Log Retention	GPO setting Event Log size and overwrite policy	logrotate setting rotation and retention days
Key Events	Logon failure (4625), Permission change (4672), Object access (4663)	`/var/log/auth.log`, auditd rules
Anti-Tampering	Forward to SIEM and set to read-only	Remote Syslog + `chattr +a` (append-only)

Windows / Linux Log Query Command Examples

powershell

# Windows: Query logon failure events (4625) from the last day
Get-WinEvent -FilterHashtable @{
  LogName = 'Security'
  Id = 4625
  StartTime = (Get-Date).AddDays(-1)
} -MaxEvents 20

# Windows: Query Security log directly with wevtutil, newest events first
wevtutil qe Security /c:20 /rd:true /f:text

bash

# Linux: View systemd journal from the last hour
sudo journalctl --since "1 hour ago"

# Linux: View logs from the previous boot cycle
sudo journalctl -b -1

# Linux: Set file to append-only, reducing risk of log overwriting
sudo chattr +a /var/log/auth.log

Get-WinEvent -FilterHashtable is suitable for precise filtering of events by LogName, Id, StartTime.
wevtutil qe is suitable for quick querying of Event Logs or exporting events.
journalctl -b -1 is commonly used to compare whether abnormalities appeared "before this boot."
chattr +a is a common practice for ext file systems, meaning the file can only be appended, not overwritten or deleted.

Log Management Key Comparison Table

Aspect	Key Description
Log Purpose	Record user activities and abnormal events, serve as post-incident tracking and legal evidence; protect Non-repudiation
Syslog Protocol	Defaults to UDP port 514 (unreliable, packets may be lost during high traffic); switch to TCP to ensure reliable delivery; use TLS (Syslog over TLS) for encrypted transmission
Centralized Management	Import logs from multiple devices/systems into SIEM for unified querying and analysis
Normalization	Log formats (field names, time formats) from different devices are inconsistent, must be unified before centralized analysis
Clock Synchronization (NTP)	Device clocks must be synchronized with a standard time source to ensure correct timing of cross-device logs, which is the basis for audit and judicial evidence
Protection and Retention	Logs must not be arbitrarily modified by administrators; retention period should meet regulatory or policy requirements

Syslog Severity Levels

Level	Value	Keyword	Description
Emergency	0	EMERG	System unusable (e.g., kernel crash)
Alert	1	ALERT	Immediate action required (e.g., primary database unresponsive)
Critical	2	CRIT	Critical error (e.g., hardware failure)
Error	3	ERR	General error, troubleshooting required
Warning	4	WARNING	Not an error but an abnormal condition worth noting
Notice	5	NOTICE	Normal but important event
Informational	6	INFO	General informational message
Debug	7	DEBUG	Detailed message for debugging, usually disabled in production

Common Log Formats

Format	Description
Syslog (RFC 5424)	Linux/Unix standard log protocol, includes Priority, Timestamp, Hostname, App-Name, Message structure
JSON	Structured logs, convenient for parsing and querying by tools like ELK (Elasticsearch + Logstash + Kibana)
CEF (Common Event Format)	Defined by HP ArcSight, semi-structured format widely supported by SIEM, fixed fields, easy to integrate across systems
LEEF (Log Event Extended Format)	Structured format used by IBM QRadar, similar to CEF but field definitions differ slightly
W3C Extended Log Format	Web server log standard, default for IIS

Easily Confused Concepts

Retaining logs protects Non-repudiation, not confidentiality or availability.
Syslog runs on UDP, packets may be lost during high traffic, which is a design characteristic of UDP not retransmitting.
Log formats from different devices are different, requiring Normalization, do not confuse with De-identification.

Log Management Best Practices

Should record: Logon success/failure, permission changes, data access, system errors, management operations.
Should not record: Passwords (including hashes), credit card numbers, PII (ID numbers, medical records), to avoid logs themselves becoming a source of data leakage.
Integrity protection: Logs should be Write Once Read Many (WORM) after being sent to prevent attackers from tampering with logs to cover intrusion traces.
Centralization: Centralize logs to SIEM or log platforms; logs scattered across hosts are difficult to correlate and analyze.
Retention period: Determined by regulations and policies (e.g., PCI DSS requires retention for at least one year, with the last three months immediately accessible).
Alert settings: Set real-time alerts for high-risk events (multiple logon failures, privileged account operations, access outside business hours).

Digital Forensics: Order of Volatility

When collecting digital evidence during incident response, evidence should be collected in order from most easily lost (most volatile) to most stable to prevent permanent loss of data after system reboot or power interruption. This principle originates from RFC 3227.

Order	Data Source	Volatility
1	CPU registers, CPU cache	Highest (disappears when power is off)
2	Main memory (RAM)	Extremely high (lost when powered off)
3	Running processes, network connection status, routing tables	High
4	Temporary files, paging file (Paging File / Swap)	Medium-high
5	Hard disk data	Medium (non-volatile, but may be overwritten by malware)
6	Remote logs, SIEM data	Low
7	Archived media (tapes, backup discs)	Lowest

Live Forensics: Capture memory image (Memory Dump) without shutting down, then perform disk image (Disk Image).
Any operation on the system (e.g., executing tool programs) may change RAM content, so evaluate carefully before collecting evidence.
Write Blocker: Must avoid any writing to the target media during collection, common practices:
- Hardware Write Blocker: External device, intercepts all write commands at the hardware level, connected between the target disk and the collection machine, preferred.
- Forensic Boot Environment: Boot from USB into Kali Forensic mode or WinPE forensic environment, local disks are not mounted to avoid OS pollution of the disk.
- Image to External Media: Use dd, FTK Imager, dcfldd to read the source and write the image to external media, the original disk is only read.

Disk Imaging Tool Comparison

Tool	Platform	Features
dd	Linux / macOS	Built-in to system, bit-for-bit copy, no progress display, no built-in hash, syntax errors may overwrite source
dcfldd	Linux	Forensic-enhanced version of dd (developed by US Department of Defense Computer Forensics Laboratory), supports calculating hash while copying, progress display, simultaneous writing to multiple targets
FTK Imager	Windows (GUI)	From AccessData, can output E01 (Expert Witness) or AD1 format, built-in hash verification, supports preview while copying

Storage Media Space Structure and Hidden Data

After obtaining a disk image, investigators, in addition to existing files, will target the following areas to find hidden or residual data:

Area	Description	Forensic Significance
Slack Space	OS allocates storage space in fixed-size Clusters. If file size is not an integer multiple of clusters, the space between the "actual file end" and "cluster end" is Slack Space	May contain residual data (content of the previous file that used the cluster), even if the original file has been deleted or overwritten, fragments in Slack Space can still be read
Unallocated Space	Sectors in the file system not occupied by any existing files. After a file is deleted, the OS only marks the cluster as "available" and does not immediately clear the data	Data can still be restored by forensic tools (e.g., Autopsy, FTK) before being overwritten by new files, commonly used to recover malicious programs or logs deleted by attackers

Windows Execution Trace Forensics (Registry and System Files)

Even if the program has been deleted, the following registry keys will retain execution records:

Location	Description
Shimcache (AppCompatCache)	`HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\AppCompatCache`, records program paths and timestamps that have been executed on the system (updated after reboot)
Amcache.hve	`C:\Windows\appcompat\Programs\Amcache.hve`, records hashes, paths, and first execution time of installed or executed applications
Prefetch (.pf)	`C:\Windows\Prefetch\`, records DLLs loaded when the program is first executed, retains execution count and last 8 execution times
MFT (Master File Table)	Core metadata table of NTFS, records attributes of every file (size, timestamp, data location); even if the file is deleted, MFT records can still be read by forensic tools. Records the "current" state of the file, does not retain historical change sequences.
$UsnJrnl (Update Sequence Number Journal)	Records the sequence of all file and directory change events within the volume (creation, deletion, renaming, data change, encryption, etc.), each record carries a USN sequence number and timestamp. Even if the target file has been deleted, the journal record still exists, making it the best source for tracking ransomware encryption behavior trajectories.
$LogFile (NTFS Transaction Journal)	Records pending or completed NTFS metadata changes for system recovery of MFT consistency after a crash. Content is in units of transactions, can be used in forensics to restore recent MFT changes, but retention time is short (circular overwrite).
$Bitmap	Records the allocation status of each cluster (0 = unused, 1 = allocated). Used in forensics to identify the scope of Unallocated Space, confirming which sectors might contain residual deleted data.

Forensic value of Shimcache / Amcache: Can prove that a specific executable once existed on the system and was executed, even if the attacker has deleted the file afterwards.
Prefetch is disabled by default on Windows Server (to improve I/O performance), and ransomware often disables Prefetch for anti-forensics.

Linux Digital Forensics Common Paths

/proc/[pid]/ is a virtual directory of Linux procfs, reflecting the runtime state of a specific process, common forensic paths are as follows:

Path	Content	Forensic Use
`/proc/[pid]/maps`	Virtual memory layout of the process, including mapped file paths and dynamic link libraries (.so)	Confirm which shared libraries the process loaded, can discover maliciously injected .so
`/proc/[pid]/cmdline`	Command line arguments used when starting the process	View process startup arguments, but cannot be read for terminated processes
`/proc/[pid]/environ`	Environment variables inherited by the process	Find hardcoded keys or settings
`/proc/[pid]/status`	Process status (PID, PPID, UID, GID, etc.)	Confirm parent-child relationship and execution identity of the process
`/proc/[pid]/fd/`	All file descriptors currently opened by the process	View files or network connections currently being read/written by the process
`~/.bash_history`	Shell history command record, written upon logout	Restore attacker operation sequence; attackers often clear with `history -c` or `unset HISTFILE`

Chain of Custody

Records the complete custody history of digital evidence from collection to court presentation, ensuring the integrity and legal validity of the evidence. Each transfer or access must be recorded:

Item	Description
Who	Identity of the person obtaining, transferring, or accessing
When	Precise timestamp
Where	Location or storage position
What	Operation content (e.g., creating disk image, transferring to forensic personnel)

If the chain of custody is broken (e.g., evidence was out of custody or access was not recorded), the court may not accept the evidence.

Hash Integrity Verification: When collecting evidence, immediately calculate a hash (usually SHA-256) for both the original media and the image, and record it in the chain of custody document. Subsequent forensic operations are performed on copies, and the hash is verified before each start. If the hash matches, it can prove to the court that the copy is bit-for-bit identical to the original media and has not been tampered with.

Platform	Command
Linux	`sha256sum disk.img`
Windows	`certutil -hashfile disk.img SHA256`

Linux Log Search and Forensic Command Examples

bash

# Use journalctl to search for SSH events in a specific time range
journalctl --since "2025-01-01 00:00:00" --until "2025-01-02 00:00:00" -u sshd

# Search for SSH brute force (logon failure records)
grep "Failed password" /var/log/auth.log | tail -20

# Count source IPs of SSH logon failures (sorted by frequency)
grep "Failed password" /var/log/auth.log \
  | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn | head -10

# Memory Dump — Using LiME kernel module
sudo insmod /opt/lime/lime-$(uname -r).ko "path=/evidence/mem.lime format=lime"

# Use dd to create bit-for-bit disk image
sudo dd if=/dev/sda of=/evidence/disk.img bs=4M status=progress

# Calculate hash of image file (ensure evidence integrity, maintain Chain of Custody)
sha256sum /evidence/disk.img > /evidence/disk.img.sha256

journalctl --since "2025-01-01 00:00:00" --until "2025-01-02 00:00:00" -u sshd is suitable for precise filtering of events by time and unit.
grep "Failed password" /var/log/auth.log is a classic way to quickly find brute force traces.
insmod is used to load the LiME kernel module for memory dumping.
dd is the standard tool for bit-for-bit disk imaging.
sha256sum is used to generate the hash for integrity verification.

Security Considerations for Log Recording

Prohibit recording sensitive data: Passwords, credit card numbers, personal ID numbers, etc., must not appear in logs.
Log integrity protection: Attackers often clear logs after intrusion to cover traces; logs should be forwarded in real-time to an independent SIEM or centralized log server.
Time synchronization: All systems should synchronize clocks via NTP to ensure the timeline of cross-system logs can be correctly correlated.
Log retention period: Set retention policy according to regulatory requirements (e.g., "Information Security Management Act" requires retention for at least 6 months) and business needs.

Memory Forensics

Memory (RAM) is the most volatile source of evidence, containing running processes, network connections, decrypted keys, and malicious code, which disappear permanently after shutdown. Volatility is the most mainstream open-source memory forensics framework, capable of analyzing memory images (Memory Dump) of Windows / Linux / macOS.

Core Analysis Targets:

Analysis Target	Volatility Common Commands (v3)	Forensic Significance
Running Processes	`windows.pslist` / `windows.pstree`	List all processes and parent-child relationships, find malicious programs disguised as system processes (e.g., fake `svchost.exe`)
Network Connections	`windows.netstat`	List all TCP/UDP connections and corresponding processes, find abnormal C2 communication connections
Injected Malicious Code	`windows.malfind`	Scan memory segments with "Executable + Readable/Writable (RWX)" protection attributes and no corresponding disk file
DLL List	`windows.dlllist`	List all DLLs loaded by the process, find abnormally injected DLLs
Registry Hive	`windows.hivelist`	List memory addresses of loaded Registry Hives, can further dump SAM / SYSTEM and other Hives

VAD (Virtual Address Descriptor) Tree Structure:

Windows kernel uses the VAD tree to record the memory segment allocation status and protection attributes of each process (e.g., PAGE_EXECUTE_READWRITE). When malicious code is injected (Process Injection, Process Hollowing), a memory segment with RWX (Read-Write-Execute) permissions is often allocated first, and then Shellcode is written; at this time, this memory segment exists in the VAD but has no corresponding physical disk file, which is a very obvious abnormal feature in the VAD tree and the main detection basis for windows.malfind.

Common Methods for Obtaining Memory Images

OS	Tool	Description
Windows	WinPmem, DumpIt, FTK Imager	Commercial or open-source tools, use kernel drivers to read physical memory and output raw / lime format
Linux	LiME (Linux Memory Extractor)	Kernel module, loaded via `insmod` to dump memory to local or transmit over network
Virtual Machine	Hypervisor Snapshot	VM snapshot directly contains memory state, easiest to obtain and cleanest for forensics

Business Continuity and Disaster Recovery

Backup Type Comparison Table

Backup Type	English	Backup Scope	Backup Time	Restore Steps	Storage Space
Full Backup	Full Backup	All data, regardless of whether it changed since the last backup	Longest	1 (Full is enough)	Largest
Differential Backup	Differential Backup	All data changed since the last Full Backup	Increasing (larger later)	2 (Latest Full + Latest Diff)	Medium
Incremental Backup	Incremental Backup	Data added or changed since the last any backup	Shortest	Multiple (Latest Full + all subsequent Inc)	Smallest

Backup Strategy Trade-offs

Full Backup = Slowest backup, simplest restore.
Differential Backup = Space larger than incremental, but restore only needs two copies (Full + Latest Diff).
Incremental Backup = Fastest backup each time, but requires chaining multiple copies during restore, most complex process.
Common strategy: Full backup on Sunday, Incremental (or Differential) from Monday to Saturday.
RPO (Recovery Point Objective): Maximum time range of data loss allowed, determined directly by backup cycle. Higher backup frequency, shorter RPO; Full backup combined with hourly Transaction Log can compress RPO to within 1 hour.
3-2-1 Backup Rule: At least 3 copies, stored on 2 different media, 1 copy off-site. This is the industry-recognized minimum standard.
WORM (Write Once Read Many) Storage: Data cannot be modified or deleted within the specified retention period after being written, effectively resisting ransomware encryption or attackers deleting backups. Cloud services (e.g., Azure Immutable Blob Storage) support WORM mode, which is an important part of modern backup strategies.

SQL Server Backup Correspondence (Industry practical example):

General Backup Type	SQL Server Correspondence	SQL Server Feature
Full Backup	Full Backup	Backs up the entire database, including data and part of transaction logs, can be restored independently
Differential Backup	Differential Backup	Backs up data pages (Data Extent) changed since the last Full, restore requires Full + Latest Diff
Incremental Backup	Transaction Log Backup	Backs up transaction logs since the last log backup, restore requires Full + all subsequent Logs applied in order

SQL Server's Transaction Log Backup concept is equivalent to incremental backup, but records "transactions" rather than "changed files."
SQL Server also has "Filegroup Backup": Backs up only specific filegroups, suitable for ultra-large databases to avoid full database backup every time.

Cross-Platform Backup Tool Comparison

Aspect	Windows	Linux
Built-in Backup Tool	`wbadmin` (Windows Server Backup), File History	`rsync`, `tar`, `cp`
Enterprise Solution	SQL Server Backup, Azure Backup	Bacula, BorgBackup, Restic
Snapshot	VSS (Volume Shadow Copy Service)	LVM Snapshot, Btrfs/ZFS Snapshot
Automatic Scheduling	Task Scheduler	`cron` / `systemd timer`
Off-site Backup	Azure Blob Storage, AWS S3	`rsync` + SSH, `rclone` (supports multi-cloud)

Linux Backup Command Examples

bash

# rsync incremental backup (only transfers changed files, suitable for off-site backup)
rsync -avz --delete /var/www/ user@backup-server:/backup/www/

# tar full backup (compresses entire directory into a single file)
tar -czf /backup/full-$(date +%Y%m%d).tar.gz /var/www/

# Combined with cron to execute incremental backup daily at 2 AM
# crontab -e
# 0 2 * * * rsync -avz --delete /var/www/ user@backup-server:/backup/www/ >> /var/log/backup.log 2>&1

# Use find to clean up backup files older than 30 days
find /backup/ -name "full-*.tar.gz" -mtime +30 -delete

rsync is the standard for incremental synchronization.
tar is the standard for archiving and compression.
cron is the standard for scheduling.
find is the standard for file management and cleanup.

Windows Backup Command Examples

powershell

# wbadmin execute full backup to network share
wbadmin start backup -backupTarget:\\BackupServer\Share -include:C: -quiet

# Use robocopy to mirror sync folder (/MIR will sync delete extra files in destination)
robocopy C:\Data \\BackupServer\Data /MIR /Z /LOG:C:\Logs\backup.log

# Create VSS snapshot (Volume Shadow Copy)
vssadmin create shadow /for=C:

wbadmin is the built-in Windows Server backup tool.
robocopy is a powerful file copying tool, /MIR is essential for mirroring.
vssadmin is used to manage VSS snapshots.

RAID (Redundant Array of Independent Disks) Comparison Table

RAID Level	Technical Principle	Minimum Disks	Allowable Failures	Read Performance	Write Performance	Available Space	Applicable Scenario
RAID 0	Striping, no redundancy. Data is split and written alternately to each disk, all disk space is merged into a single logical disk volume	2	0 (any disk failure results in total data loss)	Highest (parallel read)	Highest	100% (sum of all disk capacities)	Video editing scratch space, scenarios needing high performance but not fault tolerance
RAID 1	Mirroring, data is completely copied to each disk	2	n-1 (as long as 1 disk remains)	High (can read from both)	No improvement (must write to both simultaneously)	50%	OS disk, scenarios valuing data security
RAID 5	Striping + Distributed Parity, parity bits are rotated across different disks for each stripe	3	1 (parity can rebuild one disk)	High	Decreased (requires Parity calculation)	(n-1)/n	NAS (Network Attached Storage), common choice balancing performance and fault tolerance

RAID 5 Parity Distribution Illustration (3 Disks)

Stripe	Disk 0	Disk 1	Disk 2
1	A1	A2	P(A)
2	B1	P(B)	B2
3	P(C)	C1	C2

P(X) = Parity block of the stripe (calculated via XOR). Parity bits for each stripe are rotated across different disks to avoid parity becoming a bottleneck on a single disk. When any disk fails, the lost block can be reconstructed by XORing the remaining data + parity (e.g., Disk 1 fails → A2 = A1 XOR P(A)).

Common RAID Misconceptions and Practical Configurations

RAID is not backup: RAID only prevents hard disk failure and cannot prevent ransomware encryption, accidental deletion, fire, etc.
Common industry combinations:
- RAID 10 (1+0) = RAID 1 Mirroring + RAID 0 Striping. Balances performance and security, common choice for database servers (e.g., SQL Server recommends RAID 10 for data files).
- RAID 50 (5+0) = RAID 5 + RAID 0. Commonly used in large storage systems.
Enterprise-grade storage usually pairs with Hot Spare disks, rebuilding automatically upon failure.

RAID 5 Intuitive Analogy

Imagine 3 notebooks to copy a story:

Notebook A writes paragraph 1, paragraph 2.
Notebook B writes paragraph 1, paragraph 3.
Notebook C writes paragraph 2, paragraph 3.

Each notebook rotates responsibility for writing the "summary page" (parity), recording the checksum value of the other two notebooks' content. If any one is lost, it can be restored from the content and summary page of the other two.

RAID 6 (Double Parity): Equals writing two summary pages per stripe, distributed on two different disks, thus can tolerate simultaneous failure of 2 disks. Requires at least 4 disks.
RAID 5 writes one parity bit, tolerates 1 failure; RAID 6 writes two parity bits, tolerates 2 failures, but write performance is lower (requires two Parity calculations).

Backup Site Type Comparison Table (Hot / Warm / Cold)

Type	English	Equipment Status	Data Real-time	Activation Time	Cost
Hot Site	Hot Site	Complete equipment identical to main site, continuously running	Real-time sync (or extremely short delay)	Within minutes (almost immediate switch)	Highest
Warm Site	Warm Site	Equipment ready but standby, requires manual startup and data sync	Periodic backup (hours to a day)	Hours to days	Medium
Cold Site	Cold Site	Only site, power, and basic infrastructure, no equipment	Requires restore from backup media	Days to weeks	Lowest

RTO / WRT / MTPD / RPO

RTO (Recovery Time Objective): Maximum time service interruption is allowed after system shutdown. Hot Site RTO is shortest; Cold Site RTO is longest.
WRT (Work Recovery Time): Additional time required to verify data integrity, tune settings, and restore normal operations after system recovery (RTO achieved). Actual interruption time felt by users = RTO + WRT.
MTPD (Maximum Tolerable Period of Disruption): Absolute upper limit of interruption time the organization can bear. Exceeding this time will cause unacceptable business damage. MTPD ≥ RTO + WRT.
RPO (Recovery Point Objective): Maximum time range of data loss allowed after a disaster, determined by backup cycle. Hot Site (real-time sync) RPO is close to 0; Cold Site (periodic backup) RPO could be days ago.
Risk Appetite drives target setting: High risk appetite (can accept longer interruption) → Allows longer RTO/RPO → Can choose lower-cost backup solutions.

RPO looks at the "past" (how much data can be lost), RTO + WRT looks at the "future" (how fast to recover), MTPD is the hard deadline.
Industry Practice: Core systems in the financial industry usually require RTO < 4 hours, RPO < 1 hour, so they mostly adopt Hot Site + real-time data sync (e.g., SQL Server Always On Availability Group).
General enterprise ERP systems can accept RTO < 24 hours, Warm Site combined with daily differential backup is sufficient.

Data Storage Tiering (Hot / Warm / Cold)

Distribute data to different cost storage tiers based on access frequency to achieve a balance between performance and cost.

Tier	Characteristics	Azure Blob Correspondence	Typical Data
Hot Storage	High frequency access, low latency, high storage cost	Hot tier	Recent transaction records, current month reports
Warm Storage	Low frequency access, lower storage cost, retrieval fee applies	Cool tier	Historical data from the last one to three years
Cold Storage	Archival use, retrieval takes hours, lowest cost	Archive tier	Old data required by regulations, archival data older than three years

Data can be automatically downgraded over time (e.g., Azure Blob Lifecycle Management) or moved manually.

Relational Database Tiering Implementation

Relational databases (e.g., SQL Server) do not have native tiering management, usually implemented in the following ways:

Partition + Filegroup: Recent partitions are placed on SSD filegroups (Hot), old data partitions are placed on HDD filegroups (Cold), data is moved after aging using Partition Switching, without row-by-row copying.
Archival Database: Batch move data exceeding the retention period to an independent historical database, keep the main database lean, historical database is for query only.

Elasticsearch has native ILM (Index Lifecycle Management): Indices can be set to automatically move from Hot nodes (SSD, responsible for write and real-time query) to Warm nodes (HDD, read-only) and then to Cold/Frozen nodes, executed automatically by the engine without manual intervention.

Data Storage Tiering vs Backup Site: Same name, different meaning

"Hot/Warm/Cold" in backup sites refers to backup readiness (whether equipment is ready, how fast it can switch); in data storage tiering, it refers to the trade-off between access frequency and cost. The two sets of terms have the same name but independent concepts.

BCP Test Type Comparison Table

Test Type	English	Description	Risk	Cost
Tabletop Exercise	Tabletop Exercise	Simulate disaster scenarios through meeting discussions, step-by-step review of plan procedures	None (discussion only)	Lowest
Structured Walk-Through	Structured Walk-Through	Representatives from each department jointly review plan content item by item, confirming roles and procedures	None	Low
Simulation Test	Simulation Test	Simulate real disaster scenarios (e.g., simulate server room fire), execute notification and response processes, but do not actually switch systems	Low	Medium
Parallel Test	Parallel Test	Backup system actually starts and processes business, runs in parallel with main system to compare results	Low (main system not interrupted)	Medium-High
Full Interruption Test	Full Interruption Test	Main system completely shut down, all business switched to backup site for operation	Highest (if backup fails, business is affected)	Highest

TIP

Parallel Test: Backup system actually processes transactions while the main system is still online, verifying backup capability without affecting formal business.
Full Interruption Test is the only way to verify "true switching capability," but the risk is highest, usually executed only after approval by senior management.
Test frequency recommendation: Tabletop exercise once every six months, parallel/interruption test at least once a year.

Relationship between BCP and DRP

BCP (Business Continuity Plan) covers the complete strategy for an organization to maintain critical business operations during a disaster; DRP (Disaster Recovery Plan) is a subset of BCP, focusing on the technical recovery of IT systems and data. Both are formulated based on the analysis results of BIA.

Aspect	BCP	DRP
Scope	Entire organization (business processes, personnel, communication, IT)	IT infrastructure (servers, network, data)
Goal	Maintain minimum business operations during a disaster	Restore IT systems to normal operating state
Key Input	BIA (Business Impact Analysis)	RTO / RPO targets from BIA, critical system list, backup architecture
Responsible Role	Senior management, business owners	IT department, security team

BIA (Business Impact Analysis) is executed before BCP/DRP formulation and is the common foundation for both. By analyzing the impact of interruption on various business processes, critical business functions are identified, and RTO, RPO, and backup priorities are set accordingly, serving as input for BCP strategy planning and DRP technical design.

Physical Security

Physical Security Control Measures Comparison Table

Control Measure	English	Description
Tailgating	Tailgating	Unauthorized personnel following closely behind authorized personnel through access control, without independent card verification
Piggybacking	Piggybacking	Authorized personnel knowingly and actively bringing in unauthorized personnel (e.g., "helping open the door")
Mantrap	Mantrap / Airlock	Double-door interlocking design, the second door can only be opened after the first door is closed, forcing individual verification
CCTV	CCTV	Closed-circuit television monitoring, provides real-time monitoring and post-incident retrieval capabilities
Visitor Management	Visitor Management	Visitor registration, wearing identification badges, full escort, badge retrieval upon departure
Environmental Control	Environmental Controls	Temperature and humidity monitoring, fire suppression systems (FM-200 gas fire suppression), Uninterruptible Power Supply (UPS), backup generators
Cable Management	Cable Management	Network line labeling and physical isolation, preventing unauthorized connection or eavesdropping

Tailgating vs Piggybacking

Tailgating: The followed person is unaware, a passive security vulnerability.
Piggybacking: The followed person is aware and actively cooperates, a behavior violating security policy.
Countermeasure: Mantrap can prevent both simultaneously because everyone must be verified independently.
Common protection combination for server rooms: Access card + Mantrap + CCTV + Visitor registration system.

Environmental Control and Fire Suppression Systems

Control Item	English	Description
HVAC	HVAC (Heating, Ventilation, and Air Conditioning)	Server rooms need to maintain 18–27°C, relative humidity 40–60%. Overheating causes equipment failure, high humidity causes condensation water to damage circuits.
Wet Pipe	Wet Pipe	Pipes are pre-filled with water, sprays immediately when fire is detected. Fastest reaction but damages electronic equipment, not applicable to server rooms.
Dry Pipe	Dry Pipe	Pipes filled with compressed air, injects water only when triggered. Suitable for low-temperature environments (anti-freeze), still sprays water, not applicable to precision equipment areas.
Pre-Action	Pre-Action	Combines smoke and temperature dual detection, injects water only when both are triggered. Reduces risk of accidental spraying, applicable to areas outside the data center core.
Gas Fire Suppression	Clean Agent	Uses inert gas or chemical gas (e.g., FM-200, Novec 1230, CO₂) instead of water. Non-conductive, leaves no residue, first choice for server rooms. CO₂ has suffocation risk, must be paired with personnel evacuation alarms.

Fire Suppression System Selection Basis

Office: Wet Pipe, lowest cost, fastest reaction.
Server room perimeter (occupied areas): Pre-Action, dual confirmation reduces accidental spraying.
Server room core (server area): Gas fire suppression (FM-200 / Novec 1230), does not damage equipment.
Unoccupied enclosed spaces: CO₂, strongest fire suppression effect but displaces oxygen, personnel must evacuate first.

Electromagnetic Shielding (TEMPEST)

TEMPEST is the electromagnetic leakage protection standard defined by the US NSA (Transient Electromagnetic Pulse Emanation Standard). Electronic equipment generates electromagnetic radiation (Emanation) during operation, which attackers can capture from a distance using high-sensitivity receivers to reconstruct screen images or keyboard input.

Protection Measure	Description
Faraday Cage	Enclose space with conductive materials (metal mesh, metal plates) to block electromagnetic waves from entering or leaving. Server room level requires integration of walls, floors, and ceilings, and all incoming/outgoing lines must pass through filters.
TEMPEST Certified Equipment	Equipment itself reduces electromagnetic radiation from the design stage, meeting NSA certification standards (e.g., NSTISSAM TEMPEST/1-92).
Distance Control	Limit the distance between sensitive equipment and building exterior walls (Zone control), utilizing the characteristic that electromagnetic signals attenuate with distance.
White Noise Generator	Emits random electromagnetic signals to cover equipment radiation, interfering with the attacker's signal capture.

TIP

TEMPEST guards against passive eavesdropping, where the attacker does not need to contact the target equipment.
Daily applications of Faraday cages: microwave oven shells, mobile phone signal shielding bags, MRI rooms.
Paired with cable management: Fiber optics do not radiate electromagnetic waves and are the preferred transmission medium for high-security environments.

Cable Management Practices

Item	Description
Structured Cabling	Follow TIA/EIA-568 standard, distinguish horizontal cabling and backbone cabling.
Labeling System	Each line end labeled with a unique identifier, corresponding to the Patch Panel Diagram, ensuring traceability.
Physical Isolation	Power lines and data lines run in separate cable trays to avoid EMI (Electromagnetic Interference). Copper cables and fiber optics managed separately.
Locked Wiring Closet	Wiring closets (IDF, Intermediate Distribution Frame) should be locked and controlled to prevent unauthorized connection or eavesdropping.
Fiber Optic Anti-Eavesdropping	Fiber optics do not radiate electromagnetic waves, eavesdropping requires physical bending of the fiber (Fiber Tapping), can be detected by optical power meters detecting abnormal attenuation.

Media Sanitization

When devices are scrapped or replaced, only formatting or deleting files cannot completely clear data, and corresponding destruction methods must be chosen based on media type:

Method	HDD (Traditional Magnetic Hard Disk)	SSD / Flash Storage
Degaussing	✅ Effective (destroys magnetic recording)	❌ Ineffective (Flash does not rely on magnetism, degaussing cannot clear data)
Overwrite / Wipe	✅ Effective (still a common Clear method for HDD, but should follow current standards and organizational procedures)	⚠️ Partially effective (SSD wear leveling may retain old data blocks, requires vendor-supported secure erase commands)
ATA Secure Erase	✅ Effective	✅ Effective (if supported by vendor, controller ensures complete clearing)
Cryptographic Erase	✅ Effective	✅ Effective (encrypt all data first, then destroy the key, data becomes unreadable, recommended method for SSD)
Physical Destruction	✅ Most thorough	✅ Most thorough (NSA requires grinding to ≤ 2mm fragments)

NIST SP 800-88 Rev. 2 "Guidelines for Media Sanitization" (September 2025) divides media sanitization into three levels:

Level	Description	Applicable Scenario
Clear	Logical clearing (overwrite), no special equipment required	General confidential data, replaced for reuse within the organization
Purge	Degaussing, ATA Secure Erase, NVMe Sanitize, or compliant cryptographic erase; can resist laboratory-level recovery attacks	Sensitive data, device moves outside organizational control
Destroy	Physical destruction, ensuring data is completely unrecoverable	Top secret level, media must be completely scrapped

Cryptographic Erase reaches Purge level conditions: encryption enabled from device configuration, uses NIST-approved algorithms like AES-256, key destruction is verifiable; if any condition is not met, it only reaches Clear level.

Common Misconceptions

SSDs cannot rely on degaussing, cryptographic erase or physical destruction should be prioritized.
"Formatting" ≠ "Clearing": Formatting only deletes file indices, the data itself remains and can be restored by forensic tools.

SP 800-88 Rev. 1 (2014) Background

Rev. 1 directly listed technical operation details (e.g., "HDD overwrite with all zeros at least once"), widely cited for years.
Rev. 2 shifts from "operation manual" to a "framework for establishing organizational-level media sanitization programs," with most technical details now referencing IEEE 2883, NSA specifications, or organization-approved standards.
Rev. 2 adds NVMe-specific guidance and explicitly specifies conditions for cryptographic erase to reach Purge level (resolving the ambiguity of Rev. 1).

Network Security

Network Attack Four Basic Types Comparison Table

Based on the CIA triad, network attacks can be divided into four basic types:

Type	Damaged Attribute	Description	Typical Technique
Interruption	Availability	Data is cut off during transmission, cannot reach destination	DDoS, cutting physical lines
Interception	Confidentiality	Eavesdropped during transmission, content leaked but transmission unaffected	Packet Sniffing, MITM eavesdropping
Modification	Integrity	Data modified by unauthorized party before being sent, receiver unaware	MITM packet tampering, SQL Injection
Fabrication	Authenticity	Forged identity or data, pretending to be someone else to send	IP Spoofing, phishing emails

TIP

Interruption → You don't receive it (Availability destroyed).
Interception → You received it, but the content was seen (Confidentiality destroyed).
Modification → You received it, but the content was changed (Integrity destroyed).
Fabrication → You received it, but the sender is fake (Authenticity destroyed).

Network Architecture and Protocol Comparison Table

OSI 7 Layers Responsibilities

OSI Layer	English	PDU	Responsibility	Common Protocols & Technologies
L7 Application	Application	Data	Faces users or applications directly, provides network service interface (e.g., browsing web, transferring files).	HTTP/HTTPS, FTP, DNS, DHCP, SSH
L6 Presentation	Presentation	Data	Responsible for data format conversion, encryption/decryption, compression, ensuring different systems can understand data formats.	SSL/TLS, JPEG, Base64
L5 Session	Session	Data	Establishes, manages, terminates sessions between two ends, handles connection synchronization and dialog control.	NetBIOS, RPC
L4 Transport	Transport	Segment/Datagram	Provides reliable or fast end-to-end (Port to Port) transmission, responsible for flow control and error recovery.	TCP (reliable), UDP (low latency)
L3 Network	Network	Packet	Responsible for logical addressing (IP address) and routing across networks, determines best path from source to destination.	IP (IPv4/v6), ICMP, BGP, OSPF
L2 Data Link	Data Link	Frame	Responsible for physical addressing (MAC address) within the same network, frame encapsulation, and error detection, controls data transmission between nodes.	Ethernet (MAC), ARP, VLAN, PPP
L1 Physical	Physical	Bit	Defines electrical, optical, or wireless signal specifications of physical transmission media, responsible for sending and receiving raw bit streams.	1000BASE-T, Wi-Fi RF, fiber optics, coaxial cable

TCP/IP Model vs OSI Comparison

The TCP/IP model has two versions: the "classic 4-layer" and the "modern practical 5-layer." The early one defined by the US Department of Defense (DoD) is 4 layers (RFC 1122). With the development of network hardware technology, mainstream textbooks and network management certifications (e.g., Cisco CCNA) generally adopt the 5-layer model (also called the hybrid model).

OSI Layer	TCP/IP 4 Layers (Classic DoD)	TCP/IP 5 Layers (Modern Practical)
L7 App / L6 Pres / L5 Sess	Application	Application
L4 Transport	Transport	Transport
L3 Network	Internet	Network
L2 Data Link	Network Access	Data Link
L1 Physical	⬆️ (Merged into Network Access)	Physical

OSI and TCP/IP Layer Comparison Diagram

TIP

Merging reasons: L5~L7 merged because modern applications handle connection, encryption, and business logic directly; L1~L2 merged because physical network cards and drivers usually operate bound together.
PDU and debugging correspondence: Find Port number → Check L4 (Wireshark); Find IP address → Check L3 (Ping, routing table); Find MAC address → Check L2 (Switch, VLAN).
TCP protocol vs TCP/IP model: TCP is a single transport protocol at L4; TCP/IP is the collective name for the entire L1~L7 internet communication architecture, even if the underlying layer uses UDP, it still runs within the TCP/IP model framework.
For the complete encapsulation/decapsulation process of each layer's PDU, see the PDU Comparison Table.

💡 Protocol Abbreviation Quick Check

Protocol Number is located in the L3 IPv4 header, identifying the upper-layer protocol used by the Payload (different from the L4 Port number, which identifies the application).

Protocol Number	Protocol	Description
1	ICMP	Network diagnostics and error reporting (ping uses this protocol)
6	TCP	Reliable transmission, has handshake and retransmission mechanisms
17	UDP	Low latency transmission, no connection guarantee
47	GRE	VPN tunnel encapsulation protocol
50	ESP	IPsec encrypted packet (common in VPN)
51	AH	IPsec authentication header, verifies only, does not encrypt
89	OSPF	Internal dynamic routing protocol

Other Protocol Abbreviations

Abbreviation	Full Name	Chinese
ARP	Address Resolution Protocol	Address Resolution Protocol
BGP	Border Gateway Protocol	Border Gateway Protocol
802.1Q	—	VLAN encapsulation standard, adds VLAN Tag to Ethernet frame (VLAN is a technical concept, 802.1Q is the implementation protocol)
PPP	Point-to-Point Protocol	Point-to-Point Protocol, used for identity authentication and line establishment for point-to-point connections, modern broadband internet (PPPoE) still uses its variants
RPC	Remote Procedure Call	Remote Procedure Call, allows programs to call functions on a remote server as if calling local functions, gRPC is the modern mainstream implementation
NetBIOS	Network Basic Input/Output System	Network Basic Input/Output System, underlying protocol for early Windows Network Neighborhood, should be disabled in modern environments

NetBIOS Security Risks

NetBIOS is an extremely outdated protocol, and it is strongly recommended to disable it completely in modern enterprise networks because:

Generates massive broadcast traffic in the internal network, consuming bandwidth.
Attackers can use NBT-NS Poisoning to spread laterally in the enterprise internal network, a common penetration technique for ransomware.
Modern Windows file sharing has switched to the more secure SMB (Port 445) and no longer needs NetBIOS.

PDU (Protocol Data Unit) Comparison Table

OSI Layer	PDU	English	Description
L5-L7 Application	Data	Data / Message	Raw data generated by the application, not yet added with any protocol header.
L4 Transport	Segment / Datagram	Segment (TCP) / Datagram (UDP)	TCP cuts data into segments and numbers them to ensure reliable transmission and order; UDP does not guarantee order or retransmit.
L3 Network	Packet	Packet	Adds source/destination IP address, determines routing path.
L2 Data Link	Frame	Frame	Adds source/destination MAC address and FCS (Frame Check Sequence) error check code.
L1 Physical	Bit	Bit	Electrical signals, optical signals, or radio waves.

Encapsulation and Decapsulation

Imagine the process of mailing a package: you put the document (Data) into an envelope, write the recipient Port (L4), then put it into an outer box with an address (L3 plus IP), and finally hand it to the courier truck (L2 converted to frame, L1 converted to electrical signal). Each extra layer is called "Encapsulation"; the recipient side拆開 (decapsulates) each layer in order.

Encapsulation order: Data → Segment / Datagram → Packet → Frame → Bit

Segment is the packaging unit for TCP, Datagram for UDP.

TCP and UDP

TCP and UDP are both L4 transport protocols, determining "how" data is sent, regardless of "where" it is sent (that is the job of L3 IP).

Aspect	TCP	UDP
Full Name	Transmission Control Protocol	User Datagram Protocol
Connection Mode	Connection-oriented (establishes connection before sending data)	Connectionless (sends directly)
Reliability	Guaranteed delivery: sequence numbers, acknowledgments, timeout retransmission	Not guaranteed: packets may be lost or out of order
Speed	Slower (extra overhead for handshake and acknowledgment)	Faster (no handshake and acknowledgment)
Common Applications	HTTP/HTTPS, SSH, SMTP, FTP	DNS query, VoIP, streaming media, QUIC

TCP Three-way Handshake

TCP must complete three steps before sending data to confirm both sides can send and receive:

Common TCP Flags

Flag	Description
SYN	Request to establish connection
ACK	Acknowledgment received
FIN	Request to terminate connection normally
RST	Force reset connection (abnormal interruption)
PSH	Request immediate delivery to application layer, do not wait for buffer to fill

Security Relevance

SYN Flood: Attacker sends massive SYN but intentionally does not complete the handshake, exhausting the server's half-open connection table, a DoS attack.
TCP RST Injection: Attacker forges RST packets to force interruption of legitimate connections, can be used to interfere with communication or censorship (commonly used by firewalls to block).
UDP Amplification: UDP connectionless nature allows attackers to forge source IPs, using services with responses far larger than requests (e.g., DNS, NTP) to amplify attack traffic, see L3-L7 Denial of Service Attack section.

Common Port Comparison Table

Port numbers are located in the L4 TCP/UDP header, used to identify which application the packet should be handed to. For example, when a browser connects to a server, the server uses Port 80 or 443 to receive the request, letting the OS know to hand the traffic to the web service rather than other programs.

Port numbers are divided into three categories based on range:

Range	English Name	Chinese Name	Description
0–1023	Well-Known Ports	Well-Known Ports	Officially assigned by IANA to common services, binding to this range on Linux/Unix requires root privileges
1024–49151	Registered Ports	Registered Ports	Third-party applications register with IANA for use, e.g., MySQL (3306), RDP (3389)
49152–65535	Ephemeral Ports	Dynamic Ports	Temporary ports dynamically allocated by the OS to clients, released after connection ends

IANA (Internet Assigned Numbers Authority)

Responsible for managing global internet number resources, including the allocation and registration of IP addresses, AS numbers, and Port numbers.

Developers usually do not need to apply to IANA for Port numbers; Ports within the Ephemeral Ports range can be used freely. Situations requiring application: developing a protocol or service intended to be public and become an industry-wide standard, then you need to apply to IANA for a fixed Registered Port so other people's systems can identify which service the Port belongs to.

Common Service Ports

Port	Protocol	Transport Layer	Description
20	FTP-DATA	TCP	FTP data transmission
21	FTP	TCP	FTP control connection
22	SSH	TCP	Encrypted remote login and file transfer (SCP/SFTP)
23	Telnet	TCP	Plaintext remote login, deprecated and insecure
25	SMTP	TCP	Email transmission (server-to-server)
53	DNS	TCP/UDP	Domain name resolution (UDP for query, TCP for zone transfer)
67/68	DHCP	UDP	67 for server side, 68 for client side, dynamic IP allocation
80	HTTP	TCP	Plaintext web transmission
110	POP3	TCP	Email retrieval (deleted from server after download)
143	IMAP	TCP	Email retrieval (mail retained on server)
161/162	SNMP	UDP	161 for query, 162 for Trap (active alert)
389	LDAP	TCP	Directory service query (plaintext)
443	HTTPS	TCP	TLS encrypted web transmission
445	SMB	TCP	Windows file sharing and Network Neighborhood
465	SMTPS	TCP	SMTP over TLS (encrypted email transmission)
514	Syslog	UDP	System log transmission (plaintext, unreliable)
587	SMTP Submission	TCP	Email client submission (requires authentication)
636	LDAPS	TCP	LDAP over TLS (encrypted directory query)
853	DoT	TCP	DNS over TLS (encrypted DNS query)
993	IMAPS	TCP	IMAP over TLS
995	POP3S	TCP	POP3 over TLS
1433	MSSQL	TCP	Microsoft SQL Server
1521	Oracle DB	TCP	Oracle Database
3306	MySQL	TCP	MySQL / MariaDB Database
3389	RDP	TCP	Windows Remote Desktop Protocol
5432	PostgreSQL	TCP	PostgreSQL Database
6379	Redis	TCP	Redis cache database (no authentication by default, do not expose directly)
8080	HTTP Alt	TCP	HTTP alternative Port, commonly used for development or Proxy
27017	MongoDB	TCP	MongoDB Database

TLS Positioning in OSI Model and HTTPS / HSTS

TLS (Transport Layer Security) spans L5 (Session Layer) and L6 (Presentation Layer) in the OSI model, but is classified as part of the application layer in the TCP/IP model. TLS is not an independent transport protocol, but provides encryption and identity authentication on top of TCP and below the application layer. Evolution of versions and security of each version, see Encryption Protocol Version Evolution Comparison Table.

HTTPS (HTTP over TLS): HTTP traffic is encrypted via TLS, default Port 443.

HSTS (HTTP Strict Transport Security): The server informs the browser via the HTTP header Strict-Transport-Security that subsequent requests to the domain must use HTTPS, preventing SSL Stripping attacks (where attackers downgrade HTTPS to HTTP).

HSTS Directive	Description
`max-age=31536000`	Time (seconds) the browser remembers this policy, in this example, one year.
`includeSubDomains`	All subdomains also forced to HTTPS.
`preload`	Adds the domain to the browser's built-in HSTS Preload List, eliminating the HTTP window before the first connection.

Joining HSTS Preload List

General HSTS requires the user to successfully connect once before the browser remembers "this site must use HTTPS." Before that, the first connection might still go over HTTP, leaving a window for attack. The Preload List is a list built into each browser at the factory; once a domain is listed, anyone visiting for the first time is forced to HTTPS directly.

Application process:

Add Strict-Transport-Security header to HTTP response, must include preload, includeSubDomains, and max-age of at least one year.
Submit domain application to hstspreload.org.
Once approved, it is incorporated into the Chromium source code, and subsequently taken by Chrome, Firefox, Edge, and Safari updates.

Note: includeSubDomains is a mandatory condition; all subdomains must support HTTPS. Once joined, if you want to remove it, you must apply separately and wait for the next browser version update to take effect; confirm that the domain can maintain HTTPS long-term before applying.

SSL Stripping Attack

Attackers intercept the first HTTP request sent by the user, maintain an HTTPS connection with the server, and return a tampered HTTP page to the victim, causing credentials to be sent in plaintext. See SSL Stripping.

C# Example: HttpClient Setting TLS 1.3

csharp

using System.Net.Http;
using System.Net.Security;
using System.Security.Authentication;

// Create HttpClientHandler specifying TLS version
SocketsHttpHandler handler = new() {
    SslOptions = new() {
        // Only allow TLS 1.2 and TLS 1.3
        EnabledSslProtocols = SslProtocols.Tls12 | SslProtocols.Tls13,
    },
};

using HttpClient client = new(handler);

// Send HTTPS request
HttpResponseMessage response = await client.GetAsync("https://example.com/api/data");
response.EnsureSuccessStatusCode();

string body = await response.Content.ReadAsStringAsync();
Console.WriteLine($"Response length: {body.Length} characters");

In practice, IHttpClientFactory should be used to manage HttpClient lifecycle to avoid Socket exhaustion issues.

DNS Security

DNSSEC (DNS Security Extensions) adds digital signatures to DNS responses, ensuring the authenticity and integrity of query results, preventing DNS Spoofing and Cache Poisoning.

Why is DNSSEC needed?

The browser receives a DNS response saying "the IP of bank.com is 1.2.3.4," how can it confirm this is not forged by an attacker?

Domain signs itself: bank.com uses a private key to generate RRSIG signatures for all DNS records and publishes the corresponding DNSKEY for verification.
Self-signing cannot be trusted: Anyone can generate a set of keys and sign them; having RRSIG and DNSKEY is not enough. The resolver also needs to confirm "whether this DNSKEY itself is legitimate."
Parent issues credentials (DS record): The .com TLD stores a DS record in its own zone, which is the hash value of the bank.com DNSKEY. The resolver compares them and finds a match, meaning .com recognizes this key as genuine.
Trace back further: Is the .com DNSKEY legitimate? The Root Zone stores the DS record for .com, and then compares it further up.
Starting point of trust: The Root Zone's public key is pre-built into all operating systems and resolvers (Trust Anchor), which is the only link in the entire chain that does not require external verification.

Chain of Trust

DNSSEC Record Types

Record Type	Full Name	Chinese	Description
RRSIG	Resource Record Signature	Resource Record Signature	Digital signature of DNS record
DNSKEY	DNS Key	DNS Key	Stores the public key of the Zone, used to verify RRSIG
DS	Delegation Signer	Delegation Signer	Hash of the child zone public key by the parent zone, establishing a chain of trust
NSEC / NSEC3	Next Secure	Next Secure Record	Proves a DNS record does not exist, NSEC3 additionally adds salt hash to prevent zone enumeration

Windows / Linux DNS Query Command Examples

powershell

# Windows / Linux Universal: Query basic A record and MX record
nslookup example.com
nslookup -type=MX example.com

# Windows: Query A record of specified DNS Server
Resolve-DnsName -Name example.com -Server 1.1.1.1 -Type A -DnsOnly

# Windows: View DNSKEY published by domain
Resolve-DnsName -Name example.com -Type DNSKEY -DnsOnly

# Windows: View DNSSEC signature record
Resolve-DnsName -Name example.com -Type RRSIG -DnsOnly

bash

# Linux: Basic query and concise output
dig example.com
dig example.com MX
dig example.com +short

# Linux: Query A record from specified DNS Server
dig @1.1.1.1 example.com A

# Linux: View DNSKEY published by domain
dig example.com DNSKEY

# Linux: View DS record of parent zone
dig com DS

Resolve-DnsName can directly specify -Server, -Type, -DnsOnly, suitable for basic DNS and DNSSEC troubleshooting on Windows systems.
dig @server name type is the most common basic format, e.g., dig @8.8.8.8 example.com MX means "query a certain record from the specified DNS server."
nslookup is suitable for basic queries; to observe DNSSEC records or more complete response fields, Resolve-DnsName and dig will be clearer.

DNSSEC vs DNS Encryption Protocols Comparison:

Protocol	Purpose	Description
DNSSEC	Integrity + Authenticity	Verifies DNS response has not been tampered with, query content remains plaintext
DoH (DNS over HTTPS)	Encrypt Query	Encapsulates DNS query in HTTPS, prevents query content from being eavesdropped, Port 443
DoT (DNS over TLS)	Encrypt Query	Encrypts DNS query with TLS, Port 853

DNSSEC vs DoH / DoT

DNSSEC does not encrypt query content: Queries and responses remain plaintext, only ensuring the response has not been tampered with. If eavesdropping prevention is needed, DoH or DoT must be used.

VPN (Virtual Private Network) Types and Protocols Comparison Table

VPN Connection Types and Technical Principles

Type	Description	Typical Protocol	Applicable Scenario
Site-to-Site VPN	Interconnects two fixed networks through an encrypted tunnel (e.g., Head Office ↔ Branch Office)	IPsec (Tunnel Mode)	Branch interconnection, cross-region data centers
Remote Access VPN	Individual users connect back to enterprise internal network from outside	SSL/TLS VPN, IPsec	Remote work, business travelers accessing internal resources

Site-to-Site VPN vs Remote Access VPN Technical Principle Differences

Technical Aspect	Site-to-Site VPN	Remote Access VPN
Connection Architecture	Gateway-to-Gateway: VPN gateway devices at both ends are responsible for establishing the encrypted tunnel, internal hosts are unaware	Host-to-Gateway: User-side device directly establishes connection with enterprise VPN server
Tunnel Establishment	Persistent Tunnel: Once configured, the tunnel exists permanently (Always-On), maintaining connection state regardless of data transmission	On-demand: Tunnel established only when user connects, tunnel disappears after disconnection, supports multiple users connecting simultaneously but independently
Network Topology	Bridge Mode: "Bridges" two different local networks into one large logical network, devices at both ends can communicate directly using internal IPs	Routing Mode: User obtains virtual IP (usually assigned by VPN server's IP Pool), routing table determines which traffic goes through VPN
IP Assignment	Static Routing: Both network segments are fixed and non-overlapping (e.g., A side uses 192.168.1.0/24, B side uses 192.168.2.0/24), routing rules pre-configured	Dynamic IP Assignment: Dynamically assigns virtual IP from DHCP Pool to connected users, supports IP address reuse
Authentication Mechanism	Device Authentication: Based on Pre-Shared Key (PSK), digital certificates, or identity verification of both gateways, authenticates the device rather than individual users	User Authentication: Based on username/password, digital certificates, or Multi-Factor Authentication (MFA), each connected user requires independent authentication
Scalability Consideration	Low Scalability: Depends on topology selection for multi-site, see table below	High Scalability: VPN server can serve thousands of concurrent connections, only need to increase server computing power
Failure Impact Scope	Large Single Point Failure Impact: Gateway failure at one end completely interrupts network interconnection between the two locations, affecting all users at that location	Small Single Point Failure Impact: Individual user connection issues do not affect others, VPN server failure can be backed up by multiple servers

Site-to-Site VPN Multi-site Topology

	Hub-and-Spoke	Full Mesh
Architecture	All branch sites only establish tunnels with the central Hub	Each site establishes tunnels directly with all other sites
Connections	N-1	N×(N-1)/2
Traffic Path	Traffic between branches must detour through Hub	Each site connects directly, no detour
Management Complexity	Low, centralized in Hub configuration	High, number of connections grows rapidly as sites increase
Latency	Higher (one extra hop)	Lower (direct connection)
Single Point Failure	Hub failure interrupts communication between all branches; in practice, Hub needs HA (High Availability) backup	Failure of any site only affects itself, other sites can still connect directly
Applicable Scenario	Many branches, Hub bandwidth sufficient	Few sites, latency-sensitive or high traffic

VPN Protocol Comparison

Protocol	Operating Layer	Encryption Method	Features
IPsec	L3 Network Layer	ESP (AES + HMAC)	Industry standard, suitable for Site-to-Site; supports Transport / Tunnel dual modes, see IPsec Operation Mode Comparison Table.
SSL/TLS VPN	L4-L7	TLS	Can be used via browser or lightweight Client, no need to install dedicated software; suitable for Remote Access.
WireGuard	L3 Network Layer	ChaCha20 + Poly1305	Modern lightweight protocol, extremely small code base (approx. 4000 lines), performance better than IPsec / OpenVPN.

Split Tunneling vs Full Tunneling

Mode	Behavior	Pros	Cons
Full Tunneling	All traffic goes through VPN tunnel	High security, all traffic protected by enterprise security policy	High bandwidth consumption, affects performance
Split Tunneling	Only enterprise resource traffic goes through VPN, rest goes through local network	Saves bandwidth, better user experience	Lower security, local traffic not protected

VPN and Zero Trust

Full Tunneling of traditional VPN ensures all traffic is inspected, but in a Zero Trust Architecture, each resource has independent access control (PEP), weakening the role of VPN.
Zero Trust does not necessarily cancel VPN, but VPN is no longer the only trust boundary.

VPN Protocol Details Supplement

IPsec IKE Two-Stage Negotiation

Stage	Name	Purpose	Output
Phase 1	IKE SA Establishment	Both sides negotiate encryption algorithms, verify identity, establish secure management channel	ISAKMP SA (Internet Security Association and Key Management Protocol SA)
Phase 2	IPsec SA Establishment	Within the secure channel of Phase 1, negotiate encryption parameters for actual data transmission	IPsec SA (a pair of unidirectional SAs, each with SPI identifier)

Phase 1 has two modes: Main Mode (6-step exchange, safer) and Aggressive Mode (3-step exchange, faster but identity protection weaker).
Phase 2 uses Quick Mode, can negotiate multiple sets of IPsec SAs.
IKEv2 simplified the negotiation process, merging Phase 1 + Phase 2 into 4 message exchanges (IKE_SA_INIT + IKE_AUTH).

WireGuard Technical Features

Based on Noise Protocol Framework, uses fixed cryptographic combinations (ChaCha20, Poly1305, Curve25519, BLAKE2s), no need to negotiate encryption algorithms.
Adopts Fixed Public Key Pairing: Each Peer pre-configures the other's public key, simplifying the identity verification process.
Uses UDP only for transmission, no TCP mode.
Core code is about 4,000 lines (vs OpenVPN approx. 100,000 lines), easy for security auditing.
Connection establishment time is usually within 100ms (IPsec / OpenVPN usually takes seconds).

SSL/TLS VPN Two Modes

Mode	Description	Applicable Scenario
Clientless	Access Web applications via browser, no need to install software	Temporary access, partners, BYOD devices
Full-tunnel Client	Install dedicated client, all traffic transmitted through TLS tunnel	Remote employees needing full network access

Clientless mode only supports Web applications and some protocols (e.g., RDP over HTML5), functionality is limited but deployment is simplest.
Full-tunnel Client provides functionality equivalent to IPsec VPN, but has stronger firewall traversal capability via TLS (using TCP 443 Port).

IPsec Operation Mode Comparison Table

Aspect	Transport Mode	Tunnel Mode
Encryption Scope	Encrypts Payload only (IP header not encrypted)	Encrypts entire original IP packet (including header), then wraps with new IP header
IP Header Visibility	Original IP header retained, real source and destination IP visible	Original IP header encrypted and hidden, outer header shows VPN gateway IP
Typical Use	End-to-End (Host-to-Host) communication	Gateway-to-Gateway (Site-to-Site VPN) or Remote Access VPN
Security	Lower (attacker can know communicating IPs)	Higher (original IP hidden, only VPN gateway IP visible)
Packet Structure	`[Original IP Header][IPsec Header][Encrypted Payload]`	`[New IP Header][IPsec Header][Encrypted (Original IP Header + Payload)]`

TIP

AH (Authentication Header): Provides integrity verification and source authentication only, does not provide encryption.
ESP (Encapsulating Security Payload): Provides encryption + integrity verification + source authentication.
In practice, most VPNs use ESP + Tunnel Mode.
Transport mode is common for secure communication between two hosts within the same local network.

QUIC Protocol and HTTP/3

QUIC is a transport layer protocol developed by Google and standardized by IETF (RFC 9000), HTTP/3 uses QUIC as the underlying layer, replacing the TCP + TLS architecture of HTTP/2.

Comparison Aspect	HTTP/2 (TCP + TLS)	HTTP/3 (QUIC)
Transport Layer	TCP	UDP (QUIC implements reliable transmission on UDP itself)
Encryption	TLS (layered, handshake independent)	Built-in encryption (QUIC handshake merged with TLS 1.3)
Connection Establishment	3-way TCP + TLS handshake (1–2 RTT)	0-RTT or 1-RTT (known servers can resume connection in 0-RTT)
Head-of-Line Blocking (HOL Blocking)	Exists at TCP layer (one packet loss blocks all streams)	None (each stream independent, single packet loss does not affect other streams)
Connection Migration	IP change requires connection rebuild	Uses Connection ID, no disconnection when changing IP / network (e.g., mobile phone switching from Wi-Fi to mobile network)
Firewall/NAT Traversal	TCP 443 widely allowed	UDP 443, may be blocked in some environments

Security Considerations:

QUIC forces the use of TLS 1.3, cannot downgrade to weaker encryption versions, security is better than negotiable TLS 1.2.
Because it uses UDP, traditional firewalls based on TCP connection state may not be able to deeply inspect QUIC traffic, posing visibility challenges for enterprises.
0-RTT data may be subject to Replay Attack, server-side needs to implement Idempotent protection for 0-RTT requests.

TIP

RTT (Round-Trip Time): Time from packet sent to response received. Higher RTT means higher latency. Establishing a connection requires several round trips, requiring several RTTs of waiting time.
TCP Three-way Handshake: TCP must complete three steps (SYN → SYN-ACK → ACK) before sending data, consuming 1 RTT. HTTPS adds TLS handshake on top, totaling 2 RTTs before data transmission can start.
Head-of-Line Blocking (HOL Blocking): TCP requires packets to arrive in order, one packet loss makes all subsequent packets queue for retransmission, even if other data streams are completely normal, they will be blocked.
Jitter (Transmission Latency Variation): Inconsistency in packet arrival time. RTT is "average round-trip latency," Jitter is "fluctuation amplitude of latency." VoIP and video conferencing are extremely sensitive to Jitter; high Jitter causes broken voice or frozen screens. Attackers can deliberately create massive Jitter through network congestion (e.g., DDoS) to reduce service quality or even trigger timeout disconnection.

NAC and 802.1X Authentication

NAC (Network Access Control) is a mechanism that performs two types of checks before a device connects to the network:

Identity Authentication: Confirm whether the device or user has the right to enter the network, usually implemented via 802.1X.
Posture Assessment: Confirm whether the endpoint security settings meet policies, including OS patches, antivirus software enabled status, whether prohibited software (e.g., P2P download tools) is installed, and whether personal firewall is enabled.

Devices that fail either check are isolated to a restricted VLAN, allowed only to access patching servers for self-patching, or directly denied connection.

NAC Architecture:

802.1X is responsible for the "Identity Authentication" part mentioned above. It is the IEEE standard Port-based Network Access Control, using EAP (Extensible Authentication Protocol) as the identity verification framework.

802.1X Three Roles:

Role	English	Description	Common Implementation
Supplicant	Supplicant	Device or software requesting network access	Windows built-in 802.1X Client, wpa_supplicant (Linux)
Authenticator	Authenticator	Network device controlling Port switch	Enterprise-grade switch, wireless AP
Authentication Server	Authentication Server	Verifies identity and determines authorization	RADIUS server (e.g., FreeRADIUS, Microsoft NPS)

802.1X Authentication Process:

EAP Common Method Comparison:

EAP itself is just a framework; actual authentication strength depends on the EAP method chosen. The core difference lies in "which side needs a certificate" and "whether a TLS tunnel is established."

EAP Method	Server Certificate	Client Certificate	Authentication Type	Features
EAP-MD5	✗	✗	Unidirectional (Server cannot be verified)	Weakest; cannot prevent MITM attacks, no longer recommended
PEAP	✓	✗	Unidirectional (Verify Server)	Establishes TLS tunnel first, client authenticates with password (MSCHAPv2) inside the tunnel; most common in Windows enterprise environments
EAP-TTLS	✓	✗	Unidirectional (Verify Server)	Similar to PEAP, but supports more inner protocols (PAP, CHAP, MSCHAPv2, etc.); better cross-platform compatibility
EAP-TLS	✓	✓	Bidirectional (Mutual Authentication)	Both sides need PKI certificates; highest security, but deployment cost is largest (requires managing client certificates)
EAP-FAST	Optional	✗	Unidirectional (Default)	Proposed by Cisco; replaces certificates with PAC (Protected Access Credential), avoiding certificate management burden

Private IP and CIDR Subnetting

Private IP Range (RFC 1918)

Private IPs are routed only within the organization, external communication requires NAT conversion to public IPs. Public IPs are assigned by IANA/ISP and are globally unique; private IPs are managed by the organization itself and can be reused across different organizations.

Private Range	CIDR	Available Hosts	Common Scenario
10.0.0.0 – 10.255.255.255	10.0.0.0/8	16,777,214	Large enterprise internal network
172.16.0.0 – 172.31.255.255	172.16.0.0/12	1,048,574	Medium enterprise
192.168.0.0 – 192.168.255.255	192.168.0.0/16	65,534	Home/Small office

CIDR Subnetting

In the CIDR prefix (/n), the first n bits are the network part, and the remaining (32 - n) bits are the host part.

Available hosts = 2^(32-n) - 2 (subtracting network address and broadcast address)

CIDR	Host Bits	Available Hosts	Applicable Scenario
/22	10	1,022	Large department (~1,000 units)
/24	8	254	General office network segment
/26	6	62	Small department
/28	4	14	Small isolated network segment
/30	2	2	Point-to-Point connection

Security Significance of Subnetting

Shrinking a subnet shrinks the Blast Radius: if one network segment is breached, the impact scope is limited to hosts within that subnet.

Practical example: Finance department 10 people → /28 (14 available IPs), even other departments in the same office building cannot directly connect.

Network Segmentation

Network segmentation cuts large networks into multiple smaller security zones, limiting lateral movement, so even if an attacker breaches one segment, they cannot directly access resources in other segments.

Implementation	English	Layer	Description
VLAN	Virtual LAN	L2	Establishes logically isolated broadcast domains on the same physical switch. Communication between different VLANs must pass through L3 routers or firewalls.
ACL	Access Control List	L3-L4	Sets rules on routers or L3 switches to filter allowed or denied traffic based on IP address, Port number, and protocol.
DMZ	Demilitarized Zone	L3-L7	Isolated buffer zone between external network (Internet) and internal network, usually places external services (Web server, Mail server, DNS). External can access DMZ, but cannot directly enter internal network; internal can access DMZ, but DMZ hosts cannot directly move laterally to internal network after being breached.
Firewall Zone	Firewall Zone	L3-L7	Divides network into zones with different trust levels (e.g., Trust / Untrust / DMZ), cross-zone traffic is checked by firewall policy.
Microsegmentation	Microsegmentation	L2-L7	Sets security policies per workload (VM / Container) in virtualized or cloud environments, realizing core principles of Zero Trust architecture.

VLAN Security

VLAN (Virtual Local Area Network) cuts multiple logically independent network segments on the same physical switch, allowing traffic from different departments (e.g., Finance VLAN 10, Engineering VLAN 20) not to interfere with each other, even if they share the same physical line. The implementation standard is 802.1Q, which adds a 4-byte VLAN Tag to the Ethernet frame, allowing the switch to determine which network segment each packet belongs to.

Port Types

Frames sent by terminal devices (computers) do not carry VLAN tags themselves, but the switch must know which VLAN the frame belongs to when forwarding. The Port type determines how the switch handles this tag at each connection point.

Type	Connection Object	Description
Access Port	Terminal device (computer, printer, IP Phone)	Belongs to a single VLAN. Terminal devices send Untagged Ethernet frames; the switch adds the 802.1Q Tag of the VLAN the Port belongs to when receiving (Ingress); strips the Tag when forwarding out (Egress). The terminal device itself is unaware of the VLAN.
Trunk Port	Between switches, switch to router	Carries traffic for multiple VLANs simultaneously. Frames are transmitted in Tagged 802.1Q format, the Tag remains unchanged throughout the Trunk link, and the receiving device must be able to interpret the VLAN Tag and forward it to the corresponding VLAN accordingly.
Native VLAN	—	VLAN to which untagged frames on a Trunk Port belong, defaults to VLAN 1, mainly used for compatibility with older devices that do not support 802.1Q. Attackers can use this mechanism to launch Double Tagging attacks (see next section), Native VLAN should be changed to an unused non-VLAN 1 ID.

Scenario Comparison

Access Port — Door to Department Office

Employees (terminal devices) do not need to wear any identification stickers inside the office because everyone in the office is from the same department. When an employee walks out of the department door, the guard at the door (Access Port) will stick a department identification sticker (VLAN Tag) on their back; it will be torn off when they enter. The terminal device does not need to know the existence of the sticker at all; sticking and tearing are handled entirely by the switch.

Trunk Port — Shared Elevator in the Building

People from the Finance department and Engineering department share the same elevator (Trunk Port). To let the guard on another floor identify which department everyone belongs to, everyone must stick on a department sticker (Tagged) before entering the elevator, and the sticker is kept throughout the elevator ride without being torn off. Upon arrival, the guard at the receiving end (another switch) sees the sticker and knows which department to guide the person to.

Native VLAN — People without stickers

If someone walks into the elevator without any stickers (Untagged frame arrives at Trunk Port), the building has a default rule: everyone is classified as "default identity" (Native VLAN, defaults to VLAN 1). Attackers can use this rule to add two layers of tags to the frame, the outer layer matches the Native VLAN, the switch strips the outer layer, and the inner tag sends the traffic into an unauthorized VLAN (i.e., Double Tagging attack).

Frame Transmission Process

VLAN Hopping Attack

Attackers exploit VLAN configuration flaws to cross VLAN boundaries and access unauthorized network segments.

Double Tagging

Vulnerability Principle: Exploits the default behavior of switches "automatically stripping tags" when processing Native VLANs, smuggling malicious packets into unauthorized network segments. This is a one-way (One-way) blind attack.

Trigger Conditions:

Environment Topology: There must be 2 or more switches on the attack path, connected via Trunk Port.
Attacker Location: The Port where the attacker is located must belong to a VLAN that matches the Trunk's Native VLAN (usually defaults to VLAN 1).

Malicious Payload Structure:

The attacker self-forges a special frame with two 802.1Q tags: [Outer Tag: Native VLAN (e.g., VLAN 1)] + [Inner Tag: Target Segment (e.g., VLAN 10)] + [Malicious Data].

Attack Execution Lifecycle (Execution Pipeline):

Switch 1 (Vulnerability Trigger Point): Receives the attacker's packet, prepares to send it into the Trunk channel. Upon discovering "Outer Tag = Native VLAN," triggers the system default rule: strip the outer tag.
Trunk (Smuggling Channel): The outer tag is torn off, the hidden [Inner Tag: VLAN 10] is exposed, and it is transmitted in this state in the Trunk.
Switch 2 (Victim Forwarding Node): Receives the packet from the Trunk. Switch 2 only sees [Inner Tag: VLAN 10], and according to normal logic, forwards it to the target host in VLAN 10 without any defense.

This attack is naturally one-way: the target host's response frame follows the normal VLAN 10 path and cannot return to the attacker, so it is mostly used to trigger target behavior (e.g., ARP poisoning, service probing), rather than two-way data theft.

Switch Spoofing (Fake Trunk)

Most switches have DTP (Dynamic Trunking Protocol) enabled by default on Ports, which automatically negotiates whether to establish a Trunk connection with the other side. The attacker host sends DTP negotiation messages, inducing the switch to promote the Port to a Trunk Port. Once negotiation succeeds, the attacker host starts receiving tagged frames for all VLANs, and VLAN isolation completely fails.

Defense Measure	Defense Object	Description
Modify Native VLAN	Double Tagging	Change Native VLAN to an unused non-VLAN 1 ID, making it impossible for the attacker to match the outer tag
Disable DTP	Switch Spoofing	Explicitly set Port to Access mode and disable auto-negotiation, prohibiting unauthorized devices from negotiating Trunk
Disable Unused Ports	Both	Set idle Ports to shutdown and assign to an isolated VLAN, reducing attack surface

SDN Security (Software Defined Networking)

In traditional networks, each switch and router contains its own Control Plane (decision logic) and Data Plane (packet forwarding). If security rules need to be updated, they must be configured on each device individually, and any missed device creates a gap. SDN decouples the control plane from the device and centralizes it to the SDN Controller, with devices only responsible for executing forwarding instructions.

Three-Layer Architecture

Component	Description
Application Layer	Network applications (e.g., load balancing, firewall policy), pass policies to the controller via Northbound API (usually REST API).
Control Layer	SDN Controller (e.g., OpenDaylight, ONOS), calculates global forwarding rules after receiving application layer instructions, then issues them to devices.
Infrastructure Layer	Physical switch/router, receives controller instructions via Southbound API (e.g., OpenFlow), does not make routing decisions itself.

Scenario Comparison

Traditional networking is like having a guard room on every floor of a building, where each guard has their own manual of entry rules and judges whether to let people in. Updating rules requires running to every guard room, and missing one creates a loophole.

The SDN approach is to establish a central control room (SDN Controller) and abolish the rule manuals in each guard room. Guards no longer judge for themselves; they report to the control room when they encounter anyone, and the control room decides whether to let them in or intercept them, then transmits the instructions back to the guard to execute.

Northbound API: Management personnel (application layer) issue policies to the control room via the internal communication system (REST API), e.g., "block this IP."
Southbound API: The control room issues specific instructions to guards on each floor via a dedicated channel (OpenFlow).

Security Advantages:

Centralized Security Policy: Define security rules uniformly on the controller and deploy them to all devices at once, avoiding inconsistencies caused by individual configuration.
Dynamic Response: When abnormal traffic is detected, the controller can modify global forwarding rules in real-time to isolate infected hosts without individual operation.
Network Visibility: The controller masters the global traffic state, facilitating anomaly detection and forensic analysis.

Security Risks:

Controller is a Single Point of Failure: Once the controller is breached, the forwarding rules of the entire network are controlled. Requires deploying HA (High Availability) clusters and strictly restricting the controller's access permissions.
Northbound API Attack: If an attacker gains application layer access, they can issue malicious instructions to the controller via REST API (e.g., open all traffic, bypass firewall rules). Requires implementing API authentication and authorization.
Southbound API Attack: If an attacker can insert forged OpenFlow messages, they can directly manipulate the switch's forwarding rules. Communication between the controller and devices must be forced to use TLS encryption.

IPv6 Security Considerations

IPv4 uses 32-bit addresses (approx. 4.3 billion), which have long been exhausted. IPv6 expands the address to 128 bits (approx. 3.4×10³⁸), which is the long-term replacement solution. Due to the massive IPv4 infrastructure, most networks are currently in a Dual Stack transition period, running IPv4 and IPv6 simultaneously. This parallel state brings new security considerations: if security policies are designed only for IPv4, IPv6 traffic becomes a blind spot.

IPsec is a mandatory support (but not mandatory to enable) in the IPv6 specification, providing native end-to-end encryption capability, which is an inherent security advantage that IPv4 does not have.

Security Risk	Description
Dual Stack Risk	When IPv4 and IPv6 are enabled simultaneously, if IPv6 lacks corresponding security policies (firewall rules, IDS intrusion detection system signatures), attackers can bypass protections targeting only IPv4.
RA Forgery	IPv6 uses SLAAC for automatic address assignment, a process dependent on RA messages sent by routers. Attackers can send forged RA messages, setting themselves as the default gateway, an effect similar to IPv4's ARP Spoofing.
IPv6 Tunnel Abuse	Transition mechanisms like Teredo, 6to4 encapsulate IPv6 packets in IPv4 for transmission, potentially bypassing firewalls and IDS that do not support IPv6.
Address Reconnaissance Difficulty	An IPv6 /64 subnet contains 2⁶⁴ addresses, traditional IP-by-IP scanning is infeasible. Attackers switch to DNS queries, multicast addresses, or EUI-64 (rules for deriving IPv6 addresses from device MAC addresses) for reconnaissance.

Defense Measure	Description
Block Unused IPv6 Traffic	If the organization has not deployed IPv6, explicitly block IPv6 traffic on the firewall, including Ports used by Teredo, 6to4 tunnels, to avoid becoming a security blind spot.
Dual Stack Policy Synchronization	If dual stack is deployed, firewall rules, IDS/IPS signatures, and log records must cover both IPv4 and IPv6 simultaneously, not just protect one end.
Enable RA Guard	Enable RA Guard on switches to allow only legitimate routers to send RA messages, blocking forged Router Advertisements.

💡 Terminology Quick Check

SLAAC: Stateless Address Autoconfiguration — IPv6 devices do not need a DHCP server, automatically generating their own IP addresses via RA messages.
RA: Router Advertisement — Messages periodically broadcast by routers, informing devices in the network segment of gateway addresses and network prefixes.
EUI-64: Extended Unique Identifier (64-bit) — Converts a device's 48-bit MAC address into a 64-bit interface identifier, used to automatically generate the host part of an IPv6 address.
Teredo / 6to4: IPv6 over IPv4 tunneling transition mechanisms — Encapsulates IPv6 packets in IPv4 for transmission, allowing pure IPv4 environments to connect to IPv6 networks.
RA Guard: Router Advertisement Guard — Switch feature, allows only designated legitimate router Ports to send RA messages, preventing forged Router Advertisements.
Dual Stack: Dual Stack — The same device enables both IPv4 and IPv6 simultaneously, currently the most common transition deployment method.

Wireless Network Encryption Comparison Table

The WPA (Wi-Fi Protected Access) series is a Wi-Fi Alliance certification standard for wireless network security, starting from the structural vulnerabilities of WEP (Wired Equivalent Privacy), evolving through WPA → WPA2 → WPA3 to strengthen encryption and authentication mechanisms.

Standard	Encryption Algorithm	Authentication Method	Key Length	Known Vulnerabilities	Current Recommendation
WEP	RC4	Open/Shared Key	40/104 bit	IV repetition attack, keys can be cracked in minutes	Disable
WPA	TKIP (RC4 improved)	PSK / 802.1X	128 bit	TKIP has Michael attack, designed as a transition scheme for WEP	Not recommended
WPA2	AES-CCMP	PSK / 802.1X	128 bit	KRACK attack (Key Reinstallation Attack), can force reuse of Nonce	Still usable, but should upgrade to WPA3
WPA3	AES-GCMP / AES-CCMP	SAE / 802.1X	128/192 bit	Dragonblood attack (patched)	Recommended

Known Vulnerability Description

IV Repetition Attack (WEP): WEP uses a 24-bit Initialization Vector (IV) paired with RC4 for stream encryption. The IV space is only 2²⁴ ≈ 16 million types, which is exhausted quickly in busy networks and starts repeating. When two packets use the same IV, ciphertext XOR can cancel out the key stream, thereby restoring plaintext or reversing the key.
Michael Attack (WPA/TKIP): TKIP (Temporal Key Integrity Protocol) is the encryption protocol for WPA, designed to strengthen WEP vulnerabilities without replacing old hardware. It still uses RC4 at the bottom, but adds per-packet keys (to avoid IV repetition) and the message integrity code Michael (to prevent forgery). Michael's design strength is insufficient; attackers can forge packets and pass verification in a short time; TKIP was an emergency transition scheme, and its overall design has inherent limitations, eventually replaced by WPA2's AES-CCMP.
KRACK (WPA2): Key Reinstallation Attack. Attackers replay message 3 of the four-way handshake, forcing the client to reinstall the key and reset the Nonce to 0. After the Nonce repeats, the AES-CCMP encryption protection fails, and attackers can decrypt packets or forge data. See the four-way handshake explanation below.
Dragonblood (WPA3/SAE): Side-channel attack targeting early implementations of SAE, inferring passwords by measuring timing differences or cache access behavior during the Dragonfly calculation process. The Wi-Fi Alliance patched this in WPA3 Revision 1, and current correct implementations are not affected.

WPA2 4-Way Handshake

The four-way handshake confirms during connection that both sides hold the same PMK (Pairwise Master Key, derived from the passphrase), and negotiates the PTK (Pairwise Transient Key) for encrypting unicast data and the GTK (Group Temporal Key) for broadcast. The PMK itself is not transmitted over the network, both sides calculate it from the passphrase.

KRACK Attack Process

The attacker disguises as a man-in-the-middle, intercepts message 4 (ACK), causing the AP to mistakenly believe the client did not receive message 3, and the AP retransmits message 3 according to the protocol. Each time the client receives message 3, it reinstalls the key and resets the Nonce to 0. After the Nonce repeats, the same key encrypts different packets, and the attacker can restore the key stream, thereby decrypting or forging packets.

WPA3 and SAE

WPA2 vs WPA3 Core Differences:

Aspect	WPA2	WPA3
Key Exchange	4-Way Handshake (PSK)	SAE (Dragonfly protocol)
Offline Dictionary Attack	Feasible (offline brute force after capturing handshake packets)	Infeasible (each handshake requires interaction, cannot be brute-forced offline)
Forward Secrecy (PFS)	Not supported	Supported (SAE generates independent session keys each time)
Open Network	No encryption	OWE (Opportunistic Wireless Encryption)
Enterprise Security	WPA2-Enterprise	WPA3-Enterprise (192-bit CNSA suite)

SAE (Simultaneous Authentication of Equals)

SAE is based on the Dragonfly key exchange protocol (RFC 7664). The core idea of Dragonfly is to map the password to a point on an elliptic curve (PWE, Password Element), and perform key exchange based on this; the password itself is never transmitted over the network, nor does it leave any material for offline comparison. Attackers must initiate a complete handshake interaction with the other side for each guess, unlike WPA2 where they can capture packets once and brute-force the password offline infinitely.

SAE handshake is divided into two stages:

Commit Stage: Both sides map the password and MAC address to a PWE (Password Element) on the elliptic curve, generate a random private value, calculate scalar and element, and exchange them. Even if the attacker captures these public values, they cannot verify password guesses without interacting with the other side.
Confirm Stage: Both sides calculate confirmation codes with the shared key and verify each other, ensuring both sides know the correct password, completing bidirectional identity authentication.

OWE (Opportunistic Wireless Encryption)

OWE is used for open networks without passwords (e.g., coffee shop Wi-Fi). Traditional open networks have no encryption at all, and anyone on the same network can eavesdrop on traffic. OWE lets each client and AP perform an ECDH key exchange during connection, establishing an independent encrypted channel for that connection, preventing passive eavesdropping.

OWE does not verify the AP's identity (open networks have no password to bind the AP), so it cannot prevent Evil Twin Attacks, only providing eavesdropping protection, not identity authentication.

WPA3 Version Description:

Version	Applicable Scenario	Core Features
WPA3-Personal	Home / Small Office	SAE replaces PSK, provides PFS
WPA3-Enterprise	Government / High-security environments	Supports 192-bit security suite (CNSA, Commercial National Security Algorithm)
OWE	Public Wi-Fi (Open Network)	Establishes independent encrypted channel for each user, no password required

Purdue Model (OT / ICS Layered Security Architecture)

The Purdue Model (Purdue Enterprise Reference Architecture, PERA) is an industrial control system (ICS / OT) security layered reference architecture, dividing the OT environment into six levels (Level 0–5) according to function, explicitly specifying the equipment, functions, and security isolation requirements for each level.

Level	Name	Equipment / Function	Description
Level 0	Field Devices	Sensor, Actuator, Motor	Bottom-level hardware directly controlling physical processes
Level 1	Control	PLC (Programmable Logic Controller), RTU (Remote Terminal Unit), DCS	Receives sensor signals, controls actuators according to logic
Level 2	Supervisory	SCADA (Supervisory Control and Data Acquisition), HMI (Human Machine Interface)	Operator interface, monitors and controls Level 1 equipment; security incidents often spread from this level
Level 3	Manufacturing Operations	MES (Manufacturing Execution System), Historian data collection server	Scheduling, production tracking, recording manufacturing data
Level 3.5 (iDMZ)	Industrial DMZ	Proxy, Jump Server, Data Diode, Firewall	Buffer isolation zone between OT (Level 3) and IT (Level 4); Ensures there is never a direct network connection between IT and OT, all data exchange must pass through proxy servers or jump servers in the iDMZ, effectively preventing IT-layer malware from directly entering the OT core.
Level 4–5	Enterprise and External Network	ERP, Business Systems, Internet	Traditional IT environment

OT Security Key Principles

The boundary between Level 1 (PLC/RTU) and Level 2 (SCADA/HMI) is the lateral movement path most often exploited by attackers: after breaching SCADA (Level 2), they can issue commands downward, directly affecting physical processes at Level 1 (e.g., Ukraine power grid attack incident).
iDMZ (Industrial DMZ): Corresponds to Level 3.5, is the necessary buffer isolation zone between OT and IT; data should be transmitted unidirectionally through proxy servers or Data Diodes in the iDMZ to prevent IT-side threats from entering the OT network in reverse.
Purdue vs Zero Trust: Zero Trust requires verifying identity for every request, but many PLC devices in OT environments lack authentication capabilities, so Zero Trust in OT environments is primarily implemented in network boundary control between Level 3–4.

💡 Terminology Quick Check

IT: Information Technology — Computer systems dealing with data, communication, and business logic, e.g., servers, databases, ERP. The core difference from OT is that IT prioritizes Confidentiality, while OT prioritizes Availability.
OT: Operational Technology — Hardware and software systems that directly control physical equipment and industrial processes.
ICS: Industrial Control System — Upper-level collective term for OT, covering control systems like PLC, SCADA.
PLC: Programmable Logic Controller — Industrial computer that receives sensor signals and controls actuators according to set logic.
RTU: Remote Terminal Unit — Data acquisition and control equipment deployed on-site, communicating with SCADA.
DCS: Distributed Control System — Industrial control architecture that distributes control functions to multiple nodes, commonly used in large manufacturing plants.
SCADA: Supervisory Control and Data Acquisition — System that centrally monitors multiple on-site devices, operators monitor and control via HMI interface.
HMI: Human Machine Interface — Graphical interface for operators to interact with industrial control systems.
MES: Manufacturing Execution System — Information system managing production scheduling and tracking manufacturing progress.
ERP: Enterprise Resource Planning — Management system integrating enterprise resources such as finance, HR, supply chain, belongs to IT side.
Data Diode: Hardware device that allows data to flow in only one direction, commonly used at the OT / IT boundary to prevent external threats from entering the OT network in reverse.

Linux / Windows Network Security Tool Comparison Table

Firewall Configuration

Function	Windows	Linux
Built-in Firewall	Windows Defender Firewall	iptables / nftables / firewalld
CLI Management	`netsh advfirewall` / PowerShell `New-NetFirewallRule`	`iptables` / `nft` / `firewall-cmd`
GUI Management	`wf.msc` (Windows Firewall with Advanced Security)	Cockpit Web Console / UFW (Uncomplicated Firewall)
Rule Persistence	Automatically saved	iptables requires `iptables-save` / `iptables-restore`; firewalld uses XML configuration files for persistence

Linux Firewall Evolution

iptables: Classic packet filtering tool for Linux 2.4+, based on the Netfilter framework. Rules organized by Chain and Table.
nftables: Introduced in Linux 3.13+, successor to iptables. Syntax is more unified, performance is better, and it has gradually replaced iptables.
firewalld: Default dynamic firewall management tool for RHEL / CentOS / Fedora. Bottom layer can use iptables or nftables. Supports Zone concept and real-time rule changes.

iptables / nftables Firewall Rule Examples

iptables Common Rules

bash

# Allow established connections and related traffic
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

# Allow SSH (Port 22)
iptables -A INPUT -p tcp --dport 22 -j ACCEPT

# Allow HTTPS (Port 443)
iptables -A INPUT -p tcp --dport 443 -j ACCEPT

# Default deny all inbound traffic
iptables -P INPUT DROP

# Save rules (Debian/Ubuntu)
iptables-save > /etc/iptables/rules.v4

nftables Equivalent Rules

bash

# Create table and chain
nft add table inet filter
nft add chain inet filter input { type filter hook input priority 0 \; policy drop \; }

# Allow established connections
nft add rule inet filter input ct state established,related accept

# Allow SSH and HTTPS
nft add rule inet filter input tcp dport { 22, 443 } accept

# Save rules
nft list ruleset > /etc/nftables.conf

Network Diagnostic Tools

Function	Windows	Linux	Description
IP Config Query	`ipconfig` / `ipconfig /all`	`ip addr` / `ifconfig` (deprecated)	View IP, subnet mask, gateway of network interface cards.
Connection Status	`netstat -an`	`ss -tulnp` / `netstat -tulnp`	View current TCP/UDP connections and listening Ports. `ss` is the modern replacement for `netstat`.
Route Tracing	`tracert`	`traceroute` / `mtr`	Trace the hop path of packets to the destination. `mtr` combines ping and traceroute.
DNS Query	`nslookup` / `Resolve-DnsName`	`dig` / `nslookup`	General query uses `nslookup`; for DNSSEC records, see DNS Security section for centralized examples.
ARP Table Query	`arp -a`	`ip neigh` / `arp -a`	View local ARP cache.

Common Network Diagnostic Command Examples

bash

# Trace route (find where packets are dropped or latency spikes)
tracert 8.8.8.8                     # Windows
traceroute 8.8.8.8                  # Linux

# View listening Ports (confirm which services are exposed externally)
netstat -ano | findstr LISTENING    # Windows
ss -tulnp                           # Linux (-t TCP, -u UDP, -l listening, -n no name resolution, -p show process)

0.0.0.0 / 127.0.0.1 / localhost Easily Confused Security Traps

Address	Semantics	Security Risk
`127.0.0.1`	Loopback address, packets do not leave the host	Service limited to local access, cannot connect from outside.
`localhost`	Hostname, defaults to `127.0.0.1` (IPv6 environment is `::1`)	`/etc/hosts` can be tampered with to point to other addresses; in dual-stack environments, if firewall rules only block `127.0.0.1`, `::1` might be missed.
`0.0.0.0`	Server binding context: listen on all network interfaces, including external interfaces	Misusing `0.0.0.0` during development exposes services intended only for local access directly to the public network.

Common traps:

Database (Redis, MySQL) in development environment bound to 0.0.0.0 and deployed directly, lacking external firewall protection, exposed directly to the public network.
127.0.0.1 inside a container is limited to the container itself, host cannot access; if host access is needed, must explicitly bind to 0.0.0.0 or host IP, and pair with firewall to restrict source IP.

Network Sniffing and Packet Capture

Tool	Platform	Description
Wireshark	Windows / Linux / macOS	GUI packet analysis tool, supports parsing hundreds of protocols.
tcpdump	Linux / macOS	CLI packet capture tool, lightweight and efficient, suitable for server environments.
tshark	Windows / Linux / macOS	CLI version of Wireshark, suitable for script automation.

tcpdump Common Commands

bash

# Capture all traffic on eth0 interface
tcpdump -i eth0

# Capture HTTPS traffic only (Port 443)
tcpdump -i eth0 port 443

# Capture traffic for a specific host
tcpdump -i eth0 host 192.168.1.100

# Capture TCP SYN packets (first step of three-way handshake)
tcpdump -i eth0 'tcp[tcpflags] & tcp-syn != 0'

# Save capture results to pcap file (for Wireshark analysis)
tcpdump -i eth0 -w capture.pcap -c 1000

# Read pcap file
tcpdump -r capture.pcap

# Exclude SSH traffic (avoid capturing own remote connection)
tcpdump -i eth0 not port 22

Wireshark Display Filter Common Syntax

text

# Filter by protocol
http
dns
tls
tcp
arp

# Filter by IP address
ip.addr == 192.168.1.100
ip.src == 10.0.0.1
ip.dst == 172.16.0.0/12

# Filter by Port
tcp.port == 443
tcp.dstport == 80

# Filter by HTTP method
http.request.method == "POST"

# Filter by DNS query name
dns.qry.name == "example.com"

# Filter by TLS version
tls.handshake.version == 0x0304  # TLS 1.3

# Filter by TCP Flag
tcp.flags.syn == 1 && tcp.flags.ack == 0  # SYN (new connection)
tcp.flags.reset == 1                       # RST (connection reset)

# Combine conditions
ip.addr == 192.168.1.0/24 && tcp.port == 443 && tls

Display Filter: Filter display among captured packets, syntax as above.
Capture Filter: Filter during capture, syntax is BPF (Berkeley Packet Filter), same as tcpdump (e.g., host 192.168.1.100 and port 443).

Cryptography

Cryptography and Data Protection Technology Comparison Table

Technology Category	Key Count	Operation Speed	Core Purpose	Common Algorithms
Symmetric Encryption	1 (Encryption and decryption share the same key)	Extremely fast	Bulk data, files, full disk encryption	AES, DES, RC4
Asymmetric Encryption	2 (Public key encrypts/Private key decrypts; Private key signs/Public key verifies)	Extremely slow	Key exchange (sending symmetric keys), digital signatures, identity authentication	RSA, ECC (Elliptic Curve)
Hash Function	None (One-way conversion, cannot be restored)	Fast	Password storage (with Salt), data integrity verification	SHA-2 (e.g., SHA-256, SHA-512), MD5 (deprecated)

Symmetric vs Asymmetric Encryption/Decryption Process Comparison

Symmetric Encryption Block Modes (ECB / CBC / CTR / GCM)

Symmetric encryption processes data block by block in fixed sizes, and the "mode" determines how blocks are chained and operated; the security gap between different modes is significant.

Mode	Full Name	Parallelizable	Security	Feature Description
ECB	Electronic Codebook	✅	❌	Identical plaintext blocks produce identical ciphertext, leaking data patterns (e.g., image contours still visible after encryption)
CBC	Cipher Block Chaining	❌	⚠️	Previous ciphertext block used as XOR input for next block, eliminates ECB pattern leakage; but cannot be parallelized, and has POODLE (Padding Oracle On Downgraded Legacy Encryption) padding vulnerability
CTR	Counter Mode	✅	✅	Converts block encryption to stream encryption, can be parallelized, good performance
GCM	Galois/Counter Mode	✅	✅ Recommended	CTR encryption + GMAC (Galois Message Authentication Code) integrity verification, belongs to AEAD (Authenticated Encryption with Associated Data) mode; TLS 1.2+ mainstream choice (AES-GCM)

Why ECB Mode is Insecure

ECB mode encrypts each block independently, and identical plaintext blocks always produce identical ciphertext blocks. This leaks data patterns: encrypting a Linux penguin (Tux) image with ECB mode still clearly reveals the penguin's outline; after switching to CBC / GCM, it becomes complete noise. ECB mode should not be used in any scenario.

ECB Mode Encryption Penguin Image Visual Comparison

Nonce and IV (Initialization Vector)

Concept	Full Name	Description
IV	Initialization Vector	In modes like CBC, CFB, XORed with the first plaintext block before encryption, ensuring identical plaintext produces different ciphertext in different encryption operations
Nonce	Number Used Once	In modes like CTR, GCM, used as the initial value for the counter, must never be reused (under the same key)

Core requirements for IV/Nonce differ by mode:

Mode	Role	Core Requirement	Recommended Length
ECB	None	—	—
CBC	IV	Unpredictable: Must be truly random; when IV is predictable, attackers can launch chosen-plaintext attacks (BEAST attack exploits this vulnerability to crack TLS Cookie)	16 bytes
CTR	Nonce	Unique: Must not repeat under the same key, not mandatorily random; distributed systems are difficult to maintain global counters, practical recommendation is still to use random numbers	12 bytes
GCM	Nonce (Specification calls it IV, refers to the same value)	Same as CTR; 12 bytes (96-bit) can directly form the initial counter block `J0`, best performance, is the official recommended length	12 bytes

Nonce/IV does not need to be secret, can be transmitted publicly with ciphertext

The key (Key) must never leak, but Nonce/IV is a public value, its role is just to make identical plaintext produce different encryption results each time. The receiver gets Nonce + Key to decrypt, standard practice is to transmit Nonce and ciphertext together.

Transmission Method	Practice	Applicable Scenario
Concatenated before ciphertext (Most common)	`[Nonce (12 bytes)][Ciphertext]`, decryption end cuts the first 12 bytes to get Nonce	API transmission, file encryption
Independent database field	Stored in database table as `EncryptedData` and `CryptoNonce` fields, SELECT together during decryption	Database field encryption
HTTP Header / JWT	Placed in `X-Nonce` Header or JWT Payload	API communication

Why GCM prefers 12-byte Nonce

GCM's underlying block size is 128-bit. When IV/Nonce is exactly 96-bit (12 bytes), the specification can directly form J0 = IV || 0^31 || 1, which is the complete 128-bit initial block after padding a 32-bit counter tail.
Subsequent counter increments only need to operate on the right 32-bit counter segment, so this is GCM's most natural and efficient practice.
If IV is not 96-bit, GCM must first map IV to J0 via GHASH, adding an extra operation, making implementation more complex and performance usually worse.
The true core risk remains reusing Nonce under the same key. Non-12 bytes does not mean it is definitely insecure, but 96-bit is the conventional choice for best interoperability and performance.

Disaster of Nonce Reuse

CTR / GCM encryption is essentially stream encryption (⊕ is XOR, bitwise comparison, same is 0, different is 1):

KS = KeyStream(Key, Nonce)    ← Determined entirely by Key and Nonce
Ciphertext = Plaintext ⊕ KS

As long as Key and Nonce are the same, KS is exactly the same. If an attacker can obtain two pieces of ciphertext encrypted with the same key and same Nonce:

C1 = P1 ⊕ KS
C2 = P2 ⊕ KS

C1 ⊕ C2 = P1 ⊕ P2    ← KS cancels out, key disappears

Specific Restoration Process

Suppose the attacker captures two ciphertexts simultaneously (e.g., after KRACK forces Nonce reset, both packets use Nonce = 0 for encryption):

	Plaintext	Hexadecimal	Description
P1	"GET "	`47 45 54 20`	HTTP request start (including trailing space, total 4 bytes), fixed format, attacker knows
P2	`PASS`	`50 41 53 53`	Target plaintext, attacker wants to know
KS	—	`A3 F2 1C 8B`	Key stream, attacker does not know

Ciphertext seen by attacker after encryption:

C1 = 47⊕A3  45⊕F2  54⊕1C  20⊕8B  =  E4 B7 48 AB
C2 = 50⊕A3  41⊕F2  53⊕1C  53⊕8B  =  F3 B3 4F D8

Attacker calculates C1 ⊕ C2, KS cancels out:

E4⊕F3  B7⊕B3  48⊕4F  AB⊕D8  =  17 04 07 73  =  P1 ⊕ P2

Restore P2 using known P1 ("GET "):

17⊕47  04⊕45  07⊕54  73⊕20  =  50 41 53 53  =  "PASS"

The attacker never obtained the key, yet completely restored P2.

GCM is even worse: When Nonce repeats, not only is plaintext leaked, but the attacker can also calculate the GMAC authentication key H, after which they can forge arbitrary packets and pass integrity verification, both encryption and authentication fail. WPA2's KRACK attack exploits this principle.

C# Example: AES-GCM Encryption/Decryption

csharp

using System.Security.Cryptography;
using System.Text;

// --- Encryption ---
byte[] key = RandomNumberGenerator.GetBytes(32); // 256-bit key
byte[] nonce = RandomNumberGenerator.GetBytes(AesGcm.NonceByteSizes.MaxSize); // 12 bytes
byte[] plaintext = Encoding.UTF8.GetBytes("Confidential Data: Account, Password, and PII");
byte[] ciphertext = new byte[plaintext.Length];
byte[] tag = new byte[AesGcm.TagByteSizes.MaxSize]; // 16 bytes
byte[] associatedData = Encoding.UTF8.GetBytes("metadata-v1"); // Additional Authenticated Data (not encrypted but integrity verified)

using (AesGcm aesGcm = new(key, AesGcm.TagByteSizes.MaxSize)) {
    aesGcm.Encrypt(nonce, plaintext, ciphertext, tag, associatedData);
}

Console.WriteLine($"Nonce:      {Convert.ToBase64String(nonce)}");
Console.WriteLine($"Ciphertext: {Convert.ToBase64String(ciphertext)}");
Console.WriteLine($"Tag:        {Convert.ToBase64String(tag)}");

// --- Decryption ---
byte[] decrypted = new byte[ciphertext.Length];

using (AesGcm aesGcm = new(key, AesGcm.TagByteSizes.MaxSize)) {
    aesGcm.Decrypt(nonce, ciphertext, tag, decrypted, associatedData);
}

Console.WriteLine($"Decrypted:  {Encoding.UTF8.GetString(decrypted)}");

Asymmetric Encryption Algorithms

Asymmetric encryption uses a pair of matching public/private keys to handle two types of tasks: "encryption/decryption" and "signature/verification," with RSA and ECC being the mainstream algorithms, established on different mathematical hard problems.

Aspect	RSA	ECC (Elliptic Curve Cryptography)
Mathematical Foundation	Difficulty of large number factorization	ECDLP (Elliptic Curve Discrete Logarithm Problem)
Key Length for Equivalent Security	2048-bit or 3072-bit	256-bit (≈ RSA 3072-bit)
Operation Speed	Slower (slower as key gets longer)	Faster (short keys achieve equivalent security)
Key and Signature Size	Larger (occupies more bandwidth and storage)	Smaller, suitable for bandwidth or storage-constrained environments
Applicable Scenario	Traditional PKI (Public Key Infrastructure), systems needing backward compatibility	IoT (Internet of Things) devices, mobile devices, TLS 1.3
Main Algorithm	Encryption: RSA-OAEP (Optimal Asymmetric Encryption Padding) Signature: RSA-PSS (Probabilistic Signature Scheme)	Signature: ECDSA (Elliptic Curve Digital Signature Algorithm) Key Exchange: ECDH (Elliptic Curve Diffie-Hellman) / ECDHE (Ephemeral version)

TIP

ECC has obvious advantages, why is RSA still mainstream?: Existing PKI infrastructure, Hardware Security Modules (HSM), and most legacy compliance standards are built around RSA; ECC is the default choice for new systems (TLS 1.3 forces ECDHE), but the legacy system base is massive, making full replacement difficult in the short term.
TLS 1.3 forces the use of ECDHE for key exchange, no longer supporting RSA static key exchange.
Quantum Computer Threat: Both RSA and ECC could be cracked by Shor's Algorithm, Post-Quantum Cryptography (PQC) is currently being standardized (NIST announced the first batch of PQC standards in 2024).
Security strength equivalence: ECC 256-bit ≈ RSA 3072-bit ≈ Symmetric Encryption 128-bit.

C# Example: RSA Encryption/Decryption and Digital Signature

csharp

using System.Security.Cryptography;
using System.Text;

// --- Generate RSA Key Pair ---
using RSA rsa = RSA.Create(2048);
byte[] publicKey = rsa.ExportRSAPublicKey();
byte[] privateKey = rsa.ExportRSAPrivateKey();

// === Encryption/Decryption (Public key encrypts → Private key decrypts) ===
byte[] plaintext = Encoding.UTF8.GetBytes("Confidential Data");

using RSA rsaEncryptor = RSA.Create();
rsaEncryptor.ImportRSAPublicKey(publicKey, out _);
byte[] encrypted = rsaEncryptor.Encrypt(plaintext, RSAEncryptionPadding.OaepSHA256);
Console.WriteLine($"Encrypted: {Convert.ToBase64String(encrypted)}");

using RSA rsaDecryptor = RSA.Create();
rsaDecryptor.ImportRSAPrivateKey(privateKey, out _);
byte[] decrypted = rsaDecryptor.Decrypt(encrypted, RSAEncryptionPadding.OaepSHA256);
Console.WriteLine($"Decrypted: {Encoding.UTF8.GetString(decrypted)}");

// === Digital Signature (Private key signs → Public key verifies) ===
byte[] document = Encoding.UTF8.GetBytes("Contract Content v1.0");

using RSA rsaSigner = RSA.Create();
rsaSigner.ImportRSAPrivateKey(privateKey, out _);
byte[] signature = rsaSigner.SignData(
    document,
    HashAlgorithmName.SHA256,
    RSASignaturePadding.Pss
);
Console.WriteLine($"Signature: {Convert.ToBase64String(signature)}");

using RSA rsaVerifier = RSA.Create();
rsaVerifier.ImportRSAPublicKey(publicKey, out _);
bool isValid = rsaVerifier.VerifyData(
    document,
    signature,
    HashAlgorithmName.SHA256,
    RSASignaturePadding.Pss
);
Console.WriteLine($"Signature verification result: {isValid}");

C# Example: ECDSA Digital Signature

csharp

using System.Security.Cryptography;
using System.Text;

// --- Generate ECDSA Key Pair (P-256 curve) ---
using ECDsa ecdsa = ECDsa.Create(ECCurve.NamedCurves.nistP256);
byte[] publicKey = ecdsa.ExportSubjectPublicKeyInfo();
byte[] privateKey = ecdsa.ExportPkcs8PrivateKey();

// --- Signature ---
byte[] document = Encoding.UTF8.GetBytes("Transaction Record #20250101-001");
byte[] signature = ecdsa.SignData(document, HashAlgorithmName.SHA256);
Console.WriteLine($"Signature: {Convert.ToBase64String(signature)}");

// --- Verification (Simulate receiver only has public key) ---
using ECDsa verifier = ECDsa.Create();
verifier.ImportSubjectPublicKeyInfo(publicKey, out _);
bool isValid = verifier.VerifyData(document, signature, HashAlgorithmName.SHA256);
Console.WriteLine($"ECDSA signature verification result: {isValid}");

// --- Key Size Comparison ---
Console.WriteLine($"ECDSA P-256 Public Key Size: {publicKey.Length} bytes");
Console.WriteLine($"ECDSA P-256 Signature Size: {signature.Length} bytes");

Application Layer Cryptography Practice (Extra protection beyond TLS)

TLS, if implemented correctly (forced TLS 1.2+, valid certificate), already provides sufficient transport encryption. The following practices are applicable to scenarios with compliance requirements or defense-in-depth needs.

Recommended Process: Backend generates time-limited asymmetric key pair

When the frontend enters the login page, call the backend API to obtain a temporary public key.
The backend generates an RSA key pair, stores the private key temporarily, sets a TTL (Time To Live), and only returns the public key.
The frontend encrypts the password with the public key and sends it.
The backend decrypts with the corresponding private key, verifies the login, and destroys the private key immediately after decryption.

Private Key Temporary Storage Scheme:

Scheme	Applicable Conditions	Note
Redis (Recommended)	Multiple instances or Redis environment	TTL automatically expires, supports horizontal scaling
Application Memory	Single instance, no Redis	Key lost after application restart, cannot be shared across instances
Database	None of the above	Requires manual cleanup of expired keys, not the first choice

Key Validity: Recommended 5–15 minutes, and designed for single use (invalidated immediately after successful decryption), preventing Replay Attack.

Key Expiration Handling: Frontend re-fetches

When the backend returns an error that the key does not exist or has expired, the frontend calls the API again to obtain a new public key and retries. It is not recommended to retain an overlap period for the previous key: login is a one-time short operation, the overlap period increases implementation complexity without almost any benefit to user experience, and having two valid private keys simultaneously expands the exposure window.

Why use asymmetric instead of symmetric?

Symmetric encryption requires sharing a key between frontend and backend. Static keys written in frontend source code are equivalent to plaintext; if dynamically issued by the backend, the delivery process itself faces the same protection problem (chicken-and-egg). The public key of asymmetric encryption can be public, even if intercepted, it can only encrypt and cannot decrypt, and the private key always remains on the backend.

Why fetch public key via API instead of static public key file?

Static public keys need to be replaced via deployment. In a frontend-backend separation architecture, it also requires coordinating frontend deployment timing (if the frontend is maintained by different teams or vendors, rotation costs are higher), leading to longer rotation cycles and larger exposure windows when keys leak. The API method can enforce validity periods and single-use, and keys can be rotated without deployment.

Hash Function

Hash functions convert input of arbitrary length into a fixed-length output (digest), possessing four core characteristics:

One-wayness: Cannot reverse-engineer the original input from the output.
Determinism: Identical input always produces identical output.
Avalanche Effect: Changing one bit of input produces a completely different output.
Collision Resistance: Difficult to find two different inputs that produce the same output (collision).

Main uses: Data integrity verification, digital signatures (signing the digest rather than the original text, reason see Digital Signature section), password storage.

Fast Hash Algorithms

Fast hashes are designed for speed, suitable for integrity verification and digital signatures. The mainstream algorithms are the SHA family:

MD5 / SHA-1: Actual collision attack cases have been discovered, should no longer be used in security scenarios (digital signatures, certificate issuance). If only detecting accidental data corruption (not malicious tampering), MD5 is technically still usable, but new systems should avoid it.
SHA-2 (SHA-256, SHA-384, SHA-512): Current mainstream standard, widely used in TLS, digital signatures, certificates. The suffix number is the output bit count (SHA-256 outputs 256 bits fixed, SHA-512 outputs 512 bits fixed), regardless of input size.
SHA-3: Another design architecture (based on Keccak sponge function, unrelated to SHA-2), serves as an alternative standard, less common.

Hash Collision: Two different inputs produce the same hash output. Collision itself does not allow attackers to reverse-engineer passwords, but it allows attackers to forge fake documents with the same hash value as the original, which is fatal to digital signature security.

C# Example: SHA-256 Hash Verification (Integrity Verification)

csharp

using System.Security.Cryptography;
using System.Text;

byte[] hash = SHA256.HashData(Encoding.UTF8.GetBytes("Important Document Content"));
Console.WriteLine(Convert.ToHexStringLower(hash));

// Verify integrity: Compare hash values of two pieces of data
byte[] hash2 = SHA256.HashData(Encoding.UTF8.GetBytes("Important Document Content"));
Console.WriteLine($"Integrity consistent: {CryptographicOperations.FixedTimeEquals(hash, hash2)}");

Salt and Pepper Comparison:

Mechanism	Storage Location	Is each data different?	Description
Salt	Database (same table as hash)	✅ Each is different	A set of random salt values for each user, prevents Rainbow Table Attack
Pepper	Environment Variable / Secrets Manager (not in database)	❌ Globally shared	Global secret value, even if the entire database leaks, cannot restore password without pepper

Can be used simultaneously: hash(password + Salt + Pepper). Salt stored in database, Pepper stored outside system settings.

Origin of Salt and Pepper Names

These two terms originate from cooking metaphors: "Add ingredients to the password, making it harder for attackers to taste the original flavor."

Salt: First proposed by Robert Morris and Ken Thompson in the Unix password system in the 1970s. Mixing random values into passwords before hashing makes identical passwords produce different hash values, rendering rainbow tables (pre-calculated hash comparison tables) ineffective.
Pepper: An extended concept, corresponding to "another seasoning." Unlike salt placed on the table (database), pepper is hidden in the kitchen safe (environment variable), so even if the table is flipped, it cannot be found.

Slow Hash Algorithms (Key Stretching)

Key Stretching increases computational cost deliberately, making brute force infeasible. The following is a comparison of mainstream slow hash algorithms:

Algorithm	Core Mechanism	Adjustable Parameters	Memory Requirement	Anti-GPU/ASIC	Note
PBKDF2	Repeated execution of HMAC (e.g., HMAC-SHA256)	Iteration count	Low	❌	.NET built-in (`Rfc2898DeriveBytes`); NIST recommended; OWASP suggests at least 600,000 iterations (SHA-256)
bcrypt	Based on Blowfish block encryption	Cost Factor	Medium (4 KB)	⚠️	Mature design, widely used; input limited to 72 bytes
scrypt	PBKDF2 + massive memory access	N (CPU/memory cost), r, p	High (adjustable)	✅	Memory-intensive design resists ASIC; parameter tuning is complex
Argon2	Memory-intensive + optional multi-threading	Memory, iterations, parallelism	High (adjustable)	✅	2015 PHC (Password Hashing Competition) winner; divided into Argon2d (anti-GPU), Argon2i (anti-side-channel), Argon2id (hybrid, recommended)

Selection Recommendation

Slow hash's core threat is "offline GPU brute force." GPU has thousands of computing cores, relying solely on iteration counts to slow down CPU has limited effect, memory hardening (Memory-Hard) is the key. If each calculation requires massive memory (e.g., 64MB), GPU's VRAM becomes the bottleneck (16GB VRAM ÷ 64MB = max 256 concurrent instances).

Selection Priority:

Argon2id (First choice): Memory, iterations, and parallelism dimensions are all adjustable; combines the advantages of Argon2d (anti-GPU/ASIC) and Argon2i (anti-side-channel). OWASP suggests minimum parameters: 64MB memory, 3 iterations, 4 parallelism.
bcrypt (Second choice): Mature and reliable, widely supported; memory requirement is only 4KB, but has a 72-byte input length limit.
scrypt: Memory requirement higher than bcrypt, but the three parameters (N / r / p) are complex to tune, less commonly used in practice.
PBKDF2 (Restricted scenarios): No memory hardening; only selected under FIPS compliance or .NET built-in API limitations.

All algorithms must be paired with random Salt to prevent rainbow table attacks.

Why NIST recommends PBKDF2, and .NET has no built-in Argon2 / bcrypt

Reason for NIST recommending PBKDF2

NIST's cryptographic standards are premised on FIPS 140 compliance. PBKDF2 uses HMAC-SHA256 or HMAC-SHA512 at the bottom, both of which are NIST-defined standards, fully compliant with the FIPS whitelist. bcrypt uses Blowfish block encryption at the bottom (not a FIPS-approved algorithm); Argon2 uses Blake2b (not included in FIPS core cryptographic modules).

PBKDF2 lacks memory hardening, NIST's corresponding approach is to require significantly increased iteration counts. OWASP suggests at least 600,000 iterations (HMAC-SHA256) to compensate for the lack of memory hardness, which still provides sufficient security mathematically while maintaining FIPS compliance.

Why .NET BCL has no built-in Argon2 / bcrypt

Three reasons:

Limitations of OS Native APIs: .NET's cryptographic classes (System.Security.Cryptography) prioritize calling OS underlying APIs (CNG on Windows, OpenSSL on Linux) rather than implementing them themselves. Windows CNG has long not provided native support for Argon2 or bcrypt, so .NET has no official encapsulation.
Historical Compatibility of ASP.NET Core Identity: The Identity framework was built on PBKDF2 (Rfc2898DeriveBytes) from the beginning. If the default algorithm is changed, password hashes in existing databases will not be verifiable. Microsoft chose to increase iteration counts generation by generation (.NET 8 default is already hundreds of thousands), rather than directly replacing the algorithm.
Design Philosophy of Lean Core: Modern .NET's strategy is to keep the core lightweight, leaving specific domains to open-source packages. Argon2 and bcrypt already have mature NuGet packages (e.g., Konscious.Security.Cryptography.Argon2, BCrypt.Net-Next), no need for official mandatory inclusion.

PBKDF2 Underlying Structure

PBKDF2 code requires passing HashAlgorithmName.SHA256, which looks like processing a fast hash, but this is PBKDF2's unique design: it is essentially executing HMAC-SHA256 repeatedly for a specified number of times (600,000 iterations), "slow" is piled up by the count, not because the underlying algorithm itself is slow.

The underlying layers of bcrypt, scrypt, and Argon2 are not directly repeated fast hashes. bcrypt uses Blowfish block encryption; scrypt adds a memory mixing function outside of PBKDF2; Argon2 uses Blake2b as the calculation unit for memory filling. This is also the fundamental reason why PBKDF2 is easier to parallelize on GPU than the other three, as GPUs are inherently good at executing massive parallel SHA operations.

C# Example: PBKDF2 Password Hashing and Verification

csharp

using System.Security.Cryptography;

// --- Generate Hash (at registration) ---
string password = "MySecureP@ssw0rd";
byte[] salt = RandomNumberGenerator.GetBytes(16);
int iterations = 600_000;
HashAlgorithmName hashAlgorithm = HashAlgorithmName.SHA256;
int keySize = 32; // 256 bits

byte[] hash = Rfc2898DeriveBytes.Pbkdf2(
    password,
    salt,
    iterations,
    hashAlgorithm,
    keySize
);

// Store in database: Base64(salt) + Base64(hash) + iterations
string saltBase64 = Convert.ToBase64String(salt);
string hashBase64 = Convert.ToBase64String(hash);
Console.WriteLine($"Salt: {saltBase64}");
Console.WriteLine($"Hash: {hashBase64}");

// --- Verify Password (at login) ---
string inputPassword = "MySecureP@ssw0rd";
byte[] storedSalt = Convert.FromBase64String(saltBase64);
byte[] storedHash = Convert.FromBase64String(hashBase64);

byte[] inputHash = Rfc2898DeriveBytes.Pbkdf2(
    inputPassword,
    storedSalt,
    iterations,
    hashAlgorithm,
    keySize
);

bool isValid = CryptographicOperations.FixedTimeEquals(inputHash, storedHash);
Console.WriteLine($"Password verification result: {isValid}");

Fast Hash vs Slow Hash: Applicable Scenarios

The only use for slow hash is: Password Storage. For other scenarios, a 100ms+ computational cost is a performance burden, not a security guarantee.

	Fast Hash	Slow Hash
Calculation Time	Nanosecond level	100ms+
Password Storage	❌ Easily brute-forced	✅
Integrity / Verification / HMAC	✅	❌ Performance infeasible

Take JWT as an example: HS256 uses HMAC-SHA256 (fast hash) to sign Header.Payload, and each API request needs to recalculate the verification once. If bcrypt is used, each verification takes 100ms, the server can verify at most dozens of Tokens per second, completely unable to serve.

Therefore, JWT should use fast hash because the security threat models of JWT and passwords are different:

Password: After an attacker steals the hash from the database, they can perform offline infinite brute force enumeration; the slower the speed, the harder the attack.
JWT HMAC: Must hold the Secret key to generate a valid signature; without the key, even knowing it uses SHA-256 cannot forge it, security relies on key secrecy, not hash speed.

Message Authentication Code (MAC)

A simple Hash can only confirm "whether the message has been tampered with," but cannot confirm "who sent it." Because anyone can easily calculate the hash value, if an attacker intercepts and tampers with the message and then attaches a new hash value, the receiver has no way to distinguish the truth.

MAC introduces a "shared secret key between both parties" on the basis of hash, simultaneously achieving two core security goals:

Data Integrity: Proves the message has not been tampered with during transmission.
Source Authentication (Identity Authentication): Proves the message indeed comes from an authorized party holding the same key.

Operation Process:

Sender: Inputs "message" and "key" together to generate a fixed-length Verification Tag, and sends it along with the message.
Receiver: After receiving the message, uses their own same key to recalculate the tag once.
Verification: If the calculated tag matches the received one, it means "the message is complete and the source is legitimate"; if they do not match, the message is directly rejected.

HMAC (Hash-based MAC)

HMAC is currently the most prevalent MAC implementation, relying on conventional hash functions (e.g., SHA-256) at the bottom.

Why not just Hash(Key ‖ Message)? The most intuitive idea is to concatenate the key directly in front of the message and then hash it. But this structure (Keyed-Hash) has a serious security vulnerability: even if an attacker does not know the key, they can intercept the packet and "append" malicious content to the end of the original message, and then use mathematical properties to deduce a new valid hash value (this technique is called Length Extension Attack).

To solve this problem, HMAC adopts a Nested Hash design architecture:

Inner Operation: Key XORed with the fixed constant ipad (0x36 × block length) defined in RFC 2104, concatenated with the message, hashed for the first time to get the inner digest.
Outer Operation: Key XORed with another fixed constant opad (0x5C × block length), concatenated with the inner digest, hashed for the second time to get the final tag.

The two constants are different, making the key derivation values of the inner and outer layers completely unrelated; the outer hash truncates the internal state of SHA-256, and the attacker cannot continue to extend from the final output, fundamentally immunizing against length extension attacks. Both XOR and the two-layer hash are completed inside the HMAC implementation library, the caller only needs to pass in K and M.

Formula: HMAC(K, M) = H((K ⊕ opad) ‖ H((K ⊕ ipad) ‖ M))

Symbol Description

‖: Concatenation, equivalent to A + B, concatenates two pieces of data head-to-tail into one.
⊕: XOR (Exclusive OR), equivalent to A ^ B, compares two pieces of data of equal length bit by bit, same is 0, different is 1.

Case: Integrity Protection of API Transfer Requests

Suppose an API protects transfer requests with a shared key, compare the differences between two MAC implementations in a length extension attack.

text

Shared Key: K = "s3cr3tKey"
Original Message: M = "amount=100&to=alice"

Scheme A — SHA256(K ‖ M) direct concatenation:

text

Sender calculates:
  Tag = SHA256("s3cr3tKey" ‖ "amount=100&to=alice")

Attacker intercepts packet, obtains (M, Tag)
SHA-256 uses Merkle–Damgård structure: final output = internal state after digesting all blocks
→ Holding Tag is equivalent to holding "internal state after digesting K ‖ M", can continue to calculate

  Append extra = "&override=9999&to=bob"
  NewTag = SHA256_continue(Tag, extra)
         ≡ SHA256("s3cr3tKey" ‖ "amount=100&to=alice" ‖ [padding] ‖ extra)
                                                                          ↑ No need to know K at all

Receiver verifies: SHA256(K ‖ Tampered Message) == NewTag  ← Matches perfectly, verification passes, attack successful

What is [padding]

After SHA-256 finishes processing the input data, it automatically performs Merkle–Damgård padding at the end to meet the 512-bit block operation requirement. Padding rules:

Mark end: Append a 1 bit at the end of the message.
Pad with zeros: Continue to append 0 bits until the last 64 bits of the entire block remain.
Record length: Write the total length of the original input in the last 64 bits.

[ Original Input K ‖ M ] [ 1 ] [ 00...pad zeros...00 ] [ Original Length (64 bits) ]
|<---------------- Exactly a multiple of 512 bits ---------------->|

The padding content is uniquely determined by the original input length, and the attacker only needs to know the length of K ‖ M to accurately deduce it, which is the fundamental reason why length extension attacks are feasible.

Scheme B — HMAC:

text

Sender calculates:
  inner = SHA256((K ⊕ ipad) ‖ M)       ← Fixed 256-bit inner digest
  Tag   = SHA256((K ⊕ opad) ‖ inner)   ← Outer layer wrapped again

Attacker similarly obtains (M, Tag), attempts to append extra, extending from Tag:

  Attacker expansion:
    SHA256((K ⊕ opad) ‖ SHA256((K ⊕ ipad) ‖ M) ‖ [padding] ‖ extra)
                               └───────────────────┘
                               inner_old (contains only M), extra is in outer layer

  True HMAC(K, M ‖ extra) expansion:
    SHA256((K ⊕ opad) ‖ SHA256((K ⊕ ipad) ‖ M ‖ extra))
                               └──────────────────────┘
                               inner_new (M ‖ extra enter inner layer together)

  inner_old ≠ inner_new → Outer layer input different → Verification must fail, attack invalid

Not all integrity requirements need HMAC

The premise of HMAC is that both parties already share a secret key, introducing the burden of key management (distribution, rotation, revocation). If the scenario only requires "confirming whether the data has been tampered with" and does not need to confirm "who sent it," use a hash function directly:

Requirement	Suitable Method	Reason
Only need to confirm data integrity, both parties trust each other	Hash (SHA-256)	No key required, anyone can verify, no management burden
Need to confirm message comes from a party holding the key	HMAC	Key gives verification identity meaning
Need non-repudiation (verifiable by third party)	Digital Signature	Public/private key separation, private key holder cannot deny

Common "hash only" scenarios: file integrity verification (SHA-256 checksum), Git commit hash, data deduplication (Content-based Deduplication).

CMAC (Cipher-based MAC)

CMAC does not rely on hash functions, but instead uses Symmetric Block Encryption (e.g., AES) at the bottom to generate verification tags, standardized by NIST SP 800-38B.

Applicable Scenario: In environments already equipped with hardware AES acceleration chips (e.g., HSM hardware security modules, IoT embedded devices, smart cards), using CMAC can share the underlying AES calculation unit, saving hardware resources, and is highly compliant with FIPS's strict compliance requirements.

MAC vs Digital Signature

	MAC (HMAC)	Digital Signature
Key Type	Symmetric (both share the same one)	Asymmetric (private key signs, public key verifies)
Non-repudiation	❌ (both can generate, cannot distinguish)	✅ (only private key holder can sign)
Verification Method	Requires shared key	Verify with public key, no prior sharing required
Speed	Fast	Slow
Typical Use	TLS record layer integrity, JWT HS256, API request signature	Certificates, code signing, contract signing

C# Example: HMAC-SHA256 Calculation and Verification

csharp

using System.Security.Cryptography;
using System.Text;

// --- Generate HMAC ---
byte[] key = RandomNumberGenerator.GetBytes(32); // 256-bit key
byte[] message = Encoding.UTF8.GetBytes("Transaction Amount: 50000, Payee Account: 1234-5678");

byte[] hmac = HMACSHA256.HashData(key, message);
Console.WriteLine($"HMAC-SHA256: {Convert.ToBase64String(hmac)}");

// --- Verify HMAC (receiver holds the same key) ---
byte[] receivedMessage = Encoding.UTF8.GetBytes("Transaction Amount: 50000, Payee Account: 1234-5678");
byte[] computedHmac = HMACSHA256.HashData(key, receivedMessage);

bool isValid = CryptographicOperations.FixedTimeEquals(hmac, computedHmac);
Console.WriteLine($"HMAC verification result: {isValid}");

// --- Tamper Detection ---
byte[] tamperedMessage = Encoding.UTF8.GetBytes("Transaction Amount: 99999, Payee Account: 1234-5678");
byte[] tamperedHmac = HMACSHA256.HashData(key, tamperedMessage);

bool isTampered = CryptographicOperations.FixedTimeEquals(hmac, tamperedHmac);
Console.WriteLine($"Tampered message verification result: {isTampered}"); // False

Digital Signature and General Encryption: Public/Private Key Usage Comparison

The two uses of asymmetric encryption, the usage direction of public/private keys is exactly opposite:

General Encryption (Sending Confidential Data)

Step	Action	Key Used
1	Sender encrypts plaintext	Receiver's Public Key
2	Receiver decrypts	Receiver's Private Key

Purpose: Confidentiality (only the receiver holding the private key can read)

Digital Signature (Verify Source and Integrity)

Step	Action	Key Used
1	Sender performs fast hash on plaintext (e.g., SHA-256) → Message Digest	—
2	Sender encrypts digest with private key → Digital Signature	Sender's Private Key
3	Transmit "Plaintext + Digital Signature"	—
4	Receiver decrypts signature with public key → Obtain Digest A	Sender's Public Key
5	Receiver performs same fast hash on plaintext (e.g., SHA-256) → Obtain Digest B	—
6	Compare Digest A and B → Match means verification passed	—

Purpose: Integrity + Non-repudiation (plaintext is transmitted in plaintext, confidentiality is not guaranteed)

TIP

Digital Signature ≠ Encryption: In the signature process, the plaintext is transmitted in plaintext, only guaranteeing "who sent it" and "whether it has been tampered with."
If both confidentiality + signature are needed: Sign first, then encrypt the whole with the receiver's public key (or symmetric key).
Why perform fast hash before signing? Asymmetric encryption is extremely slow, signing an entire document directly is impractical; the digest after fast hash is fixed length (e.g., SHA-256 = 256 bits), signature speed is much faster. Here, slow hash is not used because signature requires integrity and efficiency, not resistance to offline brute force.

Digital Envelope

Digital Envelope combines the advantages of symmetric and asymmetric encryption, is the most common hybrid encryption method in practice:

Sender generates a one-time symmetric key (Session Key), uses it to encrypt data (fast speed).
Uses the receiver's public key to encrypt the symmetric key (only encrypts the short key, asymmetric encryption can afford it).
Transmits the encrypted data and the encrypted symmetric key together.
Receiver uses their own private key to decrypt the symmetric key, then uses the symmetric key to decrypt the data.

Difference from digital signature:

Mechanism	Protection Goal	Key Used
Digital Envelope	Confidentiality (only receiver can read)	Receiver's public key encrypts, receiver's private key decrypts
Digital Signature	Integrity + Non-repudiation (confirm source)	Sender's private key signs, sender's public key verifies

Key exchange in TLS handshake is essentially an application of digital envelope.

Selection timing for symmetric vs asymmetric vs hybrid encryption

Scenario	Recommended Scheme	Reason
Bulk data encryption (disk, file, database)	Symmetric Encryption (AES-GCM)	Fast speed, suitable for bulk data
Key exchange, digital signature	Asymmetric Encryption (RSA / ECC)	Solves key distribution problem, provides identity verification
Network transmission (TLS, email encryption)	Hybrid Encryption (Digital Envelope)	Combines advantages of both: asymmetric key exchange + symmetric data encryption
Password storage	Key Stretching (Argon2id / bcrypt)	One-way hash, no decryption needed
Data integrity verification	HMAC / Digital Signature	HMAC suitable for shared keys; signature suitable for public verification

PKI (Public Key Infrastructure) Trust Chain

Component	English	Description
Root CA	Root CA	Top of the trust chain, self-signed certificate, built into browser/OS trust list
Intermediate CA	Intermediate CA	Issued by Root CA, signs end-entity certificates on behalf, reduces risk of Root CA private key exposure
Registration Authority (RA)	Registration Authority	CA's identity verification front-end, responsible for verifying applicant identity (e.g., domain ownership, organizational documents), notifies CA to issue certificate after approval; CA itself does not directly contact applicants
End-Entity Certificate	End-Entity Certificate	Certificate used by websites or services, issued by Intermediate CA
Certificate Revocation List (CRL)	Certificate Revocation List	Periodically published list of revoked certificates, client must actively download and check
Online Certificate Status Protocol (OCSP)	Online Certificate Status Protocol	Real-time query of revocation status of a single certificate, more real-time than CRL

TIP

Trust chain verification process: Browser receives server certificate → Check issuer (Intermediate CA) → Trace back to Root CA → Confirm Root CA is in trust list.
OCSP Stapling: Server queries its own certificate status from CA on behalf, attaches result to TLS handshake and transmits to client, avoiding client directly connecting to CA (reduces latency and privacy risk).

C# Example: X.509 Certificate Loading and Verification

csharp

using System.Security.Cryptography;
using System.Security.Cryptography.X509Certificates;
using System.Text;

// --- Load PFX certificate (with private key) ---
string pfxPath = "server.pfx";
string pfxPassword = "P@ssw0rd";
using X509Certificate2 cert = new(pfxPath, pfxPassword, X509KeyStorageFlags.EphemeralKeySet);

Console.WriteLine($"Subject:    {cert.Subject}");
Console.WriteLine($"Issuer:     {cert.Issuer}");
Console.WriteLine($"Not Before: {cert.NotBefore:yyyy-MM-dd}");
Console.WriteLine($"Not After:  {cert.NotAfter:yyyy-MM-dd}");
Console.WriteLine($"Thumbprint: {cert.Thumbprint}");
Console.WriteLine($"Algorithm:  {cert.SignatureAlgorithm.FriendlyName}");
Console.WriteLine($"Has PK:     {cert.HasPrivateKey}");

// --- Verify Certificate Chain ---
using X509Chain chain = new();
chain.ChainPolicy.RevocationMode = X509RevocationMode.Online;
chain.ChainPolicy.RevocationFlag = X509RevocationFlag.EntireChain;
chain.ChainPolicy.VerificationFlags = X509VerificationFlags.NoFlag;

bool isChainValid = chain.Build(cert);
Console.WriteLine($"<br />Certificate chain verification result: {isChainValid}");

foreach (X509ChainElement element in chain.ChainElements) {
    Console.WriteLine($"  [{element.Certificate.Subject}]");
    foreach (X509ChainStatus status in element.ChainElementStatus) {
        Console.WriteLine($"    Status: {status.StatusInformation}");
    }
}

// --- RSA Signature with Certificate ---
using RSA? rsaPrivateKey = cert.GetRSAPrivateKey();
if (rsaPrivateKey is not null) {
    byte[] data = Encoding.UTF8.GetBytes("Data to sign");
    byte[] signature = rsaPrivateKey.SignData(
        data,
        HashAlgorithmName.SHA256,
        RSASignaturePadding.Pss
    );
    Console.WriteLine($"<br />RSA Signature: {Convert.ToBase64String(signature)}");

    using RSA? rsaPublicKey = cert.GetRSAPublicKey();
    bool verified = rsaPublicKey!.VerifyData(
        data,
        signature,
        HashAlgorithmName.SHA256,
        RSASignaturePadding.Pss
    );
    Console.WriteLine($"Signature verification: {verified}");
}

HSM (Hardware Security Module)

HSM is a physical device specifically designed to protect cryptographic keys, providing a tamper-resistant security environment:

Aspect	Description
Core Function	Key generation, storage, and usage are all completed inside the hardware, private keys never leave the HSM
Tamper-Resistant Design	Automatically destroys keys when physically disassembled (Zeroization)
Compliance Standard	FIPS 140-2 / FIPS 140-3 (US Federal Standard), divided into Level 1–4
Common Use	Root CA key protection, bank transaction signature, TLS private key protection, code signing
Cloud Form	AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM

TIP

Difference between HSM and software key management (e.g., Azure Key Vault, AWS KMS): HSM guarantees keys are calculated within a FIPS-verified hardware boundary, software solutions' keys may briefly appear in memory.
Enterprise PKI root CA private keys are usually stored in offline HSMs (not connected to the internet), enabled only when issuing Intermediate CA certificates.

Key Archiving and Escrow

Mechanism	English	Description	Risk
Key Archiving	Key Archiving	Organization keeps copies of encryption keys itself to decrypt historical data in the future (e.g., reading files encrypted by an employee after they leave)	Archival storage itself becomes an attack target
Key Escrow	Key Escrow	Key copies are kept by a trusted third party (e.g., government agency or notary), can be retrieved under specific conditions (e.g., court order)	Third party breached or abuses power, causing large-scale key leakage

Key archiving is usually only applicable to encryption keys, signature keys should not be archived (otherwise others can impersonate signatures).
Archived keys must be stored with high-strength encryption and access permissions strictly restricted (e.g., multi-party holding decryption).

TLS (Transport Layer Security)

Version Evolution Comparison Table (SSL → TLS)

Version	Release Year	Current Status	Major Changes and Milestones
SSL 2.0	1995	Deprecated (RFC 6176)	Initial public version, serious design flaws: MAC uses MD5, a fast hash, handshake lacks integrity protection, cannot prevent replay attacks.
SSL 3.0	1996	Deprecated (RFC 7568)	Significantly corrected SSL 2.0, but still has POODLE (Padding Oracle On Downgraded Legacy Encryption) attack, exploiting CBC (Cipher Block Chaining) padding flaws, overall design cannot be patched.
TLS 1.0	1999	Deprecated (RFC 8996)	Redefined based on SSL 3.0, introduced HMAC (Hash-based Message Authentication Code) to replace MAC, but fixed IV (Initialization Vector) makes BEAST (Browser Exploit Against SSL/TLS) attack feasible.
TLS 1.1	2006	Deprecated (RFC 8996)	Added explicit IV to fix BEAST vulnerability, limited improvements, primarily a transition version.
TLS 1.2	2008	Widely deployed, still valid	Introduced AEAD (Authenticated Encryption with Associated Data) encryption mode (AES-GCM); replaced MD5/SHA-1 with fast hashes like SHA-256; supports ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) to achieve PFS (Perfect Forward Secrecy).
TLS 1.3	2018	Current Standard	Removed all weak algorithms (RSA static key exchange, RC4, DES, 3DES); forced PFS; handshake reduced from 2-RTT to 1-RTT; supports 0-RTT fast reconnection.

TLS Version Evolution

SSL 2.0 / 3.0: Fundamental design flaws, deprecated entirely, should not be used in any scenario.
TLS 1.0 / 1.1: Extension patch of SSL, limited progress, fully deprecated by mainstream browsers in 2021.
TLS 1.2: Modern HTTPS foundational milestone, introduced AEAD + SHA-256 + ECDHE, currently widely deployed. The SHA-256 here is for fast hash purposes, used for handshake integrity and cryptographic operations like HMAC / PRF.
TLS 1.3: Cleared all room for "backward compatibility" compromises, forced PFS, faster handshake.

TLS 1.2 Handshake Process (ECDHE Key Exchange)

The purpose of TLS handshake is to securely establish symmetric encryption keys over an insecure network. The following is the complete process of TLS 1.2 using ECDHE key exchange:

Step	Direction	Action	Transmission State	Purpose
1	Client → Server	Client Hello	Plaintext	Inform supported Cipher Suite, TLS version, Client Random
2	Server → Client	Server Hello	Plaintext	Selected cipher suite, return Server Random
3	Server → Client	Certificate	Plaintext	Present X.509 certificate (containing server public key) for client to verify identity
4	Server → Client	Server Key Exchange	Plaintext (with signature)	Send ECDHE ephemeral public key, signed with server's long-term private key to ensure parameters not tampered with
5	Client → Server	Client Key Exchange	Plaintext	Send client's ECDHE ephemeral public key
6	Both sides	Calculate Pre-Master Secret	Not transmitted	Both sides use the other's ECDHE public key + own ECDHE private key, independently calculate the same value
7	Both sides	Derive Session Key	Not transmitted	Derive symmetric encryption key using Client Random + Server Random + Pre-Master Secret
8	Both sides	Change Cipher Spec	Plaintext	Inform the other side: subsequent messages use symmetric encryption
9	Both sides	Finished	Encrypted	First encrypted message, verifies integrity of the entire handshake process; verification basis belongs to fast hash family cryptographic operations
10	Both sides	Application Data Transmission	Symmetric Encryption	All subsequent data transmitted using Session Key encryption

TIP

Why not use asymmetric encryption directly for data? Asymmetric encryption is extremely slow (hundreds to thousands of times slower than symmetric), only used in the handshake phase to negotiate symmetric keys.
E (Ephemeral) in ECDHE stands for "temporary key": a new key pair is generated for each connection, even if the server's long-term private key leaks later, past communications cannot be decrypted, which is PFS (Perfect Forward Secrecy).
Signature in Step 4 uses the server's long-term private key (corresponding to the public key in the certificate), not the ECDHE ephemeral private key. Before signing, it also performs fast hash on parameters, the purpose is to let the client confirm "these ECDHE parameters indeed come from the real server."
TLS 1.3 Simplification: Removed Change Cipher Spec, handshake reduced from 2-RTT to 1-RTT; supports 0-RTT fast reconnection (but has replay attack risk).

TLS 1.3 Improvements

Aspect	TLS 1.2	TLS 1.3
Key Exchange	Supports RSA static key exchange (no PFS)	Only allows ECDHE / DHE (forced PFS)
Handshake Latency	2-RTT	1-RTT (supports 0-RTT fast reconnection)
Cipher Suite	Supports CBC, RC4, etc. old modes	Only allows AEAD (AES-GCM, ChaCha20-Poly1305)
Hash Algorithm	Supports MD5, SHA-1	Only allows fast hashes SHA-256 and above
Handshake Encryption	Most of handshake is plaintext	Handshake messages encrypted after Server Hello
0-RTT	Not supported	Supported (has replay attack risk, use with caution)

Practical recommendation: New systems should default to TLS 1.3; if backward compatibility for old clients is needed, allow TLS 1.2 but must disable RSA key exchange and CBC mode.

Perfect Forward Secrecy (PFS)

PFS ensures that past encrypted communications remain secure even if the server's long-term private key leaks:

Key Exchange Method	PFS	Description
RSA Static Key Exchange	❌	Client encrypts Pre-Master Secret with server public key; after server private key leaks, all historical traffic can be decrypted
DHE / ECDHE (Ephemeral Key)	✅	Each connection generates a new ephemeral key pair; ephemeral private key destroyed after connection ends, even if long-term private key leaks, it cannot be retrospectively decrypted

TLS 1.3 forces the use of ECDHE, guaranteeing all connections have PFS at the protocol level.

Diffie-Hellman Key Exchange and MITM Attack Risk

Diffie-Hellman (DH) allows both sides to negotiate a shared key over an insecure channel, but the original DH protocol does not provide identity authentication, making it vulnerable to Man-in-the-Middle (MitM) attacks:

Countermeasure: In TLS, DH/ECDHE parameters must be paired with the server's digital signature (first perform fast hash on parameters, then sign with long-term private key), allowing the client to verify that the parameters indeed come from a legitimate server. This is the role of TLS handshake step 4 (Server Key Exchange + Signature).

Cryptographic Attack Techniques

Attack Type	English	Description	Target
Birthday Attack	Birthday Attack	Exploits birthday paradox, finds hash collision in approx 2^(n/2) attempts (n is hash bit count). E.g., 128-bit hash only needs approx 2^64 attempts	Hash functions (MD5, SHA-1)
Length Extension Attack	Length Extension Attack	For hash functions with Merkle–Damgård structure (MD5, SHA-1, SHA-2), after attacker holds output of H(secret ‖ message), they can calculate new valid hash after appending extra content without knowing secret. Commonly used to attack MACs implemented as "key directly concatenated before message then hashed"	Hash functions; MACs implemented as H(key ‖ message)
Known Plaintext Attack	Known Plaintext Attack	Attacker possesses partial "plaintext + corresponding ciphertext" pairs, deduces key or decrypts other ciphertexts	Symmetric encryption
Chosen Plaintext Attack	Chosen Plaintext Attack	Attacker can choose arbitrary plaintext and obtain its ciphertext (e.g., access to encryption Oracle), deducing key	Symmetric/Asymmetric encryption
Chosen Ciphertext Attack	Chosen Ciphertext Attack	Attacker can choose ciphertext and obtain decryption result, reverse-engineer key. RSA is particularly vulnerable without padding	Asymmetric encryption
Side-Channel Attack	Side-Channel Attack	Deduces key through physical characteristics like execution time, power consumption, electromagnetic radiation, rather than directly attacking algorithm mathematics	All cryptographic implementations
Replay Attack	Replay Attack	Intercepts and resends legitimate encrypted messages (e.g., authentication Token), impersonating legitimate user	Authentication protocols
Padding Oracle Attack	Padding Oracle Attack	Exploits server's different responses to padding errors to decrypt ciphertext byte by byte (e.g., POODLE, Lucky 13)	CBC mode padding
Downgrade Attack	Downgrade Attack	Forces both parties to use weaker encryption versions or algorithms (e.g., POODLE forces downgrade back to SSL 3.0)	Protocol negotiation

Defense Key Points

Birthday Attack: Use hash functions of 256-bit or more (SHA-256+), collision requires 2^128 attempts.
Length Extension Attack: Use HMAC instead of H(key ‖ message); or switch to SHA-3 (Keccak sponge function structure, naturally immune to this attack).
Side-Channel Attack: Use constant-time comparison (e.g., CryptographicOperations.FixedTimeEquals), avoid Timing Attack.
Downgrade Attack: Disable all known insecure protocol versions and cipher suites.

Birthday Attack: Why is it called "Birthday"?

Birthday Paradox: In a room, you only need 23 people to have a >50% probability that two people share the same birthday. Intuitively this number is very low (there are 365 days in a year), but the counter-intuitive key is: we are looking for any pair that matches, not "someone sharing a birthday with a specific person."

There are 23 × 22 ÷ 2 = 253 pairs to compare among 23 people, so the probability rises rapidly.

Attack Target	Cost	Analogy
Pre-image Attack: Find input corresponding to specific hash value	2^n attempts	Find someone who shares a birthday with a specific person
Collision Attack: Find any two inputs with same hash value	2^(n/2) attempts	Find any two people in the room who share a birthday

The cost of collision attack is only "half the exponent" of pre-image attack, so collision attack must be considered when choosing hash length.

SHA-1 (160-bit): Collision theory requires 2^80 attempts, Google found a collision in 2017 (SHAttered project), SHA-1 officially declared insecure.
SHA-256 (256-bit): Collision requires 2^128 attempts, currently uncrackable.

Padding Oracle Attack: How to decrypt ciphertext byte by byte?

CBC decryption formula: P_i = D(C_i) ⊕ C_{i-1}, where D is block decryption, C is ciphertext, P is plaintext.

PKCS#7 Padding Rules: Plaintext end must be padded to 16 bytes. If missing k bytes, pad k bytes with value k:

Missing 1 byte  → pad 01
Missing 2 bytes → pad 02 02
Missing 3 bytes → pad 03 03 03

Attack Principle: Server returns "padding error" if format is invalid after decryption. This error response is an "Oracle" (queryable black box), attacker restores plaintext byte by byte through it:

Take the last ciphertext block C_n and the previous one C_{n-1}.
Try modifying the last byte of C_{n-1} one by one (256 possibilities).
When server returns "padding correct," it means the last byte after decryption is exactly 0x01.
Deduce: D(C_n)[last] = 0x01 ⊕ test value, then reverse-deduce real plaintext: P_n[last] = D(C_n)[last] ⊕ original C_{n-1}[last].
After knowing the last byte, adjust expected padding to 02 02, repeat deduction for the second-to-last byte, until the entire block is restored.

Each byte takes at most 256 queries, 16 bytes per block takes at most 4,096 queries to decrypt an entire block. POODLE and Lucky 13 attacks belong to this category.

For a complete explanation of side-channel attacks (including timing attack byte-by-byte case, law of large numbers, Spectre and cloud co-residency), see Common Software Vulnerability Exploitation Techniques Comparison Table.

Downgrade Attack: How to forge "insufficient capability" to trick server into using old protocol?

The first step of TLS handshake, client sends ClientHello, declaring supported protocol versions and cipher suite list, server selects the highest version from them to respond.

Attack Process (using POODLE as an example):

Attacker (MITM) intercepts client's ClientHello.
Tamper the supported version list from TLS 1.3, 1.2, 1.1, 1.0, SSL 3.0 to only SSL 3.0.
Server receives it and thinks the other side only supports SSL 3.0, downgrades negotiation according to specification.
SSL 3.0's CBC padding rules have POODLE vulnerability, attacker can then decrypt traffic.

Why is attack feasible: To be compatible with old clients (old browsers, old devices), servers usually enable multiple versions simultaneously; as long as the old version is open, the downgrade target exists.

Defense:

Server-side: Explicitly disable all versions below TLS 1.1, leaving old versions nowhere to downgrade to.
TLS 1.3: Embeds a Downgrade Sentinel in the Finished message hash; if the server detects that ClientHello was tampered with, it terminates the handshake.

Common Cryptographic Tool Command Examples

OpenSSL Common Commands

bash

# --- Generate RSA private key (2048-bit) ---
openssl genpkey -algorithm RSA -out private.pem -pkeyopt rsa_keygen_bits:2048

# --- Export public key from private key ---
openssl pkey -in private.pem -pubout -out public.pem

# --- Generate ECDSA private key (P-256 curve) ---
openssl genpkey -algorithm EC -out ec-private.pem -pkeyopt ec_paramgen_curve:P-256

# --- Generate self-signed certificate (valid for 365 days) ---
openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes \
  -subj "/C=TW/ST=Taipei/L=Taipei/O=MyOrg/CN=localhost"

# --- View certificate content ---
openssl x509 -in cert.pem -text -noout

# --- View remote server certificate chain ---
openssl s_client -connect www.google.com:443 -showcerts </dev/null 2>/dev/null | \
  openssl x509 -text -noout

# --- Verify certificate ---
openssl verify -CAfile ca-bundle.pem cert.pem

# --- AES-256-CBC encrypt file (using PBKDF2 to derive key) ---
openssl enc -aes-256-cbc -salt -pbkdf2 -in plain.txt -out encrypted.bin

# --- AES-256-CBC decrypt file ---
openssl enc -aes-256-cbc -d -pbkdf2 -in encrypted.bin -out decrypted.txt

# --- Calculate SHA-256 hash ---
openssl dgst -sha256 file.txt

# --- HMAC-SHA256 ---
openssl dgst -sha256 -hmac "my-secret-key" file.txt

Official documentation: https://docs.openssl.org/master/man1/openssl/

GPG Common Commands

bash

# --- Generate key pair ---
gpg --full-generate-key

# --- List keys ---
gpg --list-keys
gpg --list-secret-keys

# --- Symmetric encrypt file (AES-256, password protected) ---
gpg --symmetric --cipher-algo AES256 -o encrypted.gpg plain.txt

# --- Symmetric decrypt ---
gpg --decrypt -o decrypted.txt encrypted.gpg

# --- Asymmetric encrypt (using recipient's public key) ---
gpg --encrypt --recipient [email protected] -o encrypted.gpg plain.txt

# --- Asymmetric decrypt ---
gpg --decrypt -o decrypted.txt encrypted.gpg

# --- Digital signature ---
gpg --sign --armor -o signed.asc document.txt

# --- Verify signature ---
gpg --verify signed.asc

# --- Export public key ---
gpg --export --armor [email protected] > public.asc

# --- Import public key ---
gpg --import public.asc

Official documentation:
- GnuPG Manuals: https://www.gnupg.org/documentation/manuals.en.html
- GNU Privacy Guard Manual: https://preview.gnupg.org/documentation/manuals/gnupg/index.html

Post-Quantum Cryptography (PQC) and Key Encapsulation Mechanism (KEM)

Post-Quantum Cryptography (PQC) is a cryptographic algorithm designed to counter the threat of quantum computers, aiming to replace traditional asymmetric encryption that relies on "large number factorization hard problems" (RSA) or "discrete logarithm hard problems" (ECC, DH). Shor's Algorithm can crack these hard problems with periodic algebraic structures in polynomial time on quantum computers; PQC switches to mathematical foundations that quantum computers cannot accelerate as the security basis.

NIST PQC Standardization Results (Official standard in 2024):

Algorithm	Chinese Description	Type	Mathematical Foundation	Standard
CRYSTALS-Kyber (ML-KEM)	Module Lattice Key Encapsulation Mechanism	Key Encapsulation (KEM)	Lattice	FIPS 203
CRYSTALS-Dilithium (ML-DSA)	Module Lattice Digital Signature Algorithm	Digital Signature	Lattice	FIPS 204
SPHINCS+ (SLH-DSA)	Stateless Hash Digital Signature Algorithm	Digital Signature	Hash Function	FIPS 205

Why Lattice-based hard problems have post-quantum security

The security of Lattice-based cryptography (Lattice-based Cryptography) is built on high-dimensional geometric hard problems such as Learning With Errors (LWE).

Intuitive understanding of LWE: Given a large number of linear equation systems with tiny random errors (b = A·s + e mod q, where A, b are known, s is the hidden secret vector, e is random error), can you reverse-engineer s?

No error (e = 0): Solve linear equations, middle school math can solve.
Add random error (e ≠ 0): The problem is exponentially difficult, currently neither classical nor quantum computers have known effective algorithms.

Shor's Algorithm uses Quantum Fourier Transform to accelerate periodic algebraic structures; the random error of LWE destroys this regularity, quantum acceleration fails here.

Key Encapsulation Mechanism (KEM):

KEM is the mechanism used in the post-quantum era to securely transmit symmetric keys, functionally equivalent to a "post-quantum digital envelope":

Receiver generates KEM public key / private key pair.
Sender performs Encapsulate with receiver's public key, generating: a ciphertext and a shared secret.
Receiver performs Decapsulate with private key, restoring the same shared secret.
Both sides communicate with symmetric encryption using the shared secret.

"Harvest Now, Decrypt Later" Attack

Attackers collect and store encrypted transmission data now, and decrypt it after quantum computers mature. Even if quantum computers are not practical today, data with long-term confidentiality needs (e.g., government secrets, medical records) needs to start migrating to PQC algorithms now.

Quantum Threat to Symmetric Encryption: Grover's Algorithm

Grover's Algorithm primarily threatens symmetric encryption systems, it can accelerate brute force at a quadratic level, effectively halving the secure key length:

Algorithm	Traditional Security Strength	Effective Strength after Quantum Computer	Conclusion
AES-128	128 bits	64 bits	❌ Insufficient, not recommended for long-term protection
AES-256	256 bits	128 bits	✅ Currently considered sufficient, NIST recommended

Symmetric encryption does not need to be replaced with PQC algorithms, increasing key length to 256 bits is sufficient to cope with Grover's Algorithm.

Quantum Key Distribution (QKD)

Quantum Key Distribution (QKD) uses quantum mechanics principles to securely exchange encryption keys between two parties, any eavesdropping behavior will interfere with the quantum state, allowing the receiver to detect it.

Operating Principle (using BB84 protocol as an example):

Sender randomly transmits photon sequences in four polarization states (↕, ↔, ↗, ↘).
Receiver randomly chooses a basis (+ type or × type) to measure each photon.
Both sides compare the bases they used over a public channel, retaining quantum bits where "bases match" as raw key material.
If an eavesdropper measures photons in transit, according to the Heisenberg Uncertainty Principle, quantum states cannot be copied (No-cloning Theorem), the measurement behavior itself changes the quantum state, causing the receiver to detect an abnormal bit error rate, and both sides discard this key.

QKD vs PQC Positioning Differences:

	QKD	PQC
Security Foundation	Quantum physics laws (Quantum No-cloning Theorem)	Mathematical hard problems (Lattice, Hash function)
Deployment Requirement	Requires dedicated quantum channel (fiber or satellite), high hardware cost	Software algorithm replacement, can operate on existing network infrastructure
Resistance Target	Any eavesdropping (even quantum computers cannot steal keys without leaving traces)	Primarily against quantum computer computational cracking (Shor's Algorithm)
Maturity	Short-distance commercial (tens to hundreds of kilometers), long-distance relies on relays or satellites	NIST announced first batch of standards in 2024, practical progress is fast
Main Limitation	Expensive equipment, distance limited, infrastructure not easy to expand	Correctness of algorithms still being continuously verified

QKD solves "whether the key exchange process is eavesdropped"; PQC solves "whether encryption can still resist cracking after computing power increases." The two goals are complementary, not mutually exclusive.
"Harvest Now, Decrypt Later" attacks can be prevented by QKD (eavesdropping can be detected at the time), but QKD's high deployment threshold makes PQC a more realistic short-term transition solution.

Homomorphic Encryption

Homomorphic encryption allows performing mathematical operations directly on ciphertext, the result after decryption is equivalent to the result of performing operations on plaintext first and then encrypting, without ever decrypting the original data.

Intuitively, ciphertext looks like a string of meaningless garbled code (e.g., Base64 or Hex), it's hard to imagine being able to "do math" on it. The key is that the design goals of the two types of encryption are different:

	Traditional Encryption (AES / RSA)	Homomorphic Encryption
Design Goal	Deliberately destroy algebraic structure, making ciphertext and plaintext completely unrelated	Deliberately preserve specific algebraic structure, making operations on ciphertext correspond to operations on plaintext
Ciphertext Operation	Perform addition/subtraction/multiplication/division on ciphertext, get meaningless results after decryption	Perform addition or multiplication on ciphertext, get correct plaintext operation results after decryption
Cost	High performance, widely applied	While preserving algebraic structure and maintaining semantic security, design is complex, performance is extremely low

Modern FHE schemes (BFV, BGV, CKKS, etc.) are built on Ring-LWE Lattice hard problems, ciphertext is essentially high-dimensional vectors/polynomials, and their algebraic structure naturally supports the transmission of addition and multiplication. This also makes FHE simultaneously possess post-quantum security.

Type	English	Supported Operations	Description
Partial Homomorphic (PHE)	Partial Homomorphic Encryption	Addition only OR Multiplication only	Implementation is simpler, RSA multiplication homomorphic belongs to this category
Somewhat Homomorphic (SHE)	Somewhat Homomorphic Encryption	Addition + Limited multiplication	Error accumulation leads to decryption failure after exceeding limit
Fully Homomorphic (FHE)	Fully Homomorphic Encryption	Addition + Multiplication (unlimited times)	Theoretically can perform arbitrary calculations, but computational overhead is extremely high

Typical Application: Cloud machine learning (cloud providers train or infer models without touching original personal data), cross-institutional medical data joint analysis (institutions analyze together without sharing original data).
Current Status of FHE: Computational overhead is far higher than plaintext calculation (currently about thousands to tens of thousands of times slower), still in the research and limited application stage.
Different purpose from PQC: PQC solves "how to make encryption resist quantum computer cracking"; homomorphic encryption solves "how to use encrypted data without decrypting it."

Attack Techniques

Malware and Attack Chain

Malware Comparison Table

Type	Independent Survival (Need host?)	Spread and Trigger Method	Main Purpose and Features	Typical Example / Note
Virus	No (needs to attach to normal file)	Needs user to click or execute host file	Destroy system, infect other files	Macro virus, CIH
Worm	Yes (independent executable)	Actively scans network vulnerabilities, self-replicates and spreads	Consumes network bandwidth and system resources	Blaster, SQL Slammer
Trojan	Yes (disguised as normal software)	Deceives user into actively downloading and installing	Steal secrets, open backdoors for remote control	Banking Trojan, RAT (Remote Access Trojan)
Ransomware	Yes	Via phishing emails, vulnerabilities, or Trojan implantation	Encrypts files, locks them, extorts decryption ransom	WannaCry (has worm spreading characteristics), LockBit
Spyware	Yes	Bundled with free software or malicious web pages	Keylogging, monitoring browsing behavior, stealing passwords	Keylogger
Logic Bomb	No (usually implanted in normal program)	Triggers only when specific conditions are met (e.g., specific date, specific operation)	Internal employee revenge, timed destruction	Malicious database deletion script

OFAC Sanction List Verification Obligation Before Paying Ransom

OFAC (Office of Foreign Assets Control, US Department of the Treasury) maintains a sanction list (SDN List), listing countries, organizations, and individuals sanctioned by the US.

For enterprises headquartered or operating within the US (or involving USD transactions):

If deciding to pay ransom, must first verify whether the attacker/payee is on the OFAC sanction list.
Providing funds to sanctioned hostile nation hacker organizations or terrorists is a serious federal felony, potentially facing huge fines or even criminal prosecution, regardless of whether it was known, and may be held accountable (strict liability).
Even if not on the sanction list, it is recommended to voluntarily disclose to OFAC after payment (voluntary disclosure can mitigate liability).

Confirming whether the target is on the list is not the primary purpose: Enterprises do not pay to avoid becoming a source of funds for sanctioned targets, not to ensure the attacker will definitely decrypt, the latter belongs to the scope of negotiation and technical assessment.

Virus Advanced Variant Technology Comparison

Polymorphic Virus: Changes its own encryption signature every time it infects, but the decrypted malicious core code remains the same. The goal is to evade traditional antivirus software signature scanning.
Metamorphic Virus: Rewrites its own code every time it infects (e.g., replacing instructions, inserting garbage code), appearance and structure are completely different, but the malicious behavior executed is the same, the most difficult type to detect.

Packing & Obfuscation

Antivirus software's static analysis scans files on the hard disk, comparing signatures of known malicious programs. Packing makes the appearance on the hard disk completely different from the real code, thereby bypassing scanning:

Packing Process:

Packer compresses/encrypts original malicious code, merges with an external shell program (Stub) responsible for unpacking into a new executable file
When antivirus scans, it sees compressed garbage + Stub, cannot find malicious signatures → passes
When user executes, Stub runs first, unpacks/decrypts original code and loads it into memory
Malicious code appears and executes only in memory

Technology	Operation Method	Attacker Goal	Common Tool/Technique
Packing	Original code compressed/encrypted and wrapped in Stub, unpacked by Stub at execution and loaded into memory	Make static appearance on hard disk different from real code, bypass signature scanning	UPX (general compression), Themida (commercial protection), custom Packer
Obfuscation	Rewriting code structure (e.g., scrambling execution flow, inserting garbage code), execution result remains unchanged	Increase time cost for reverse engineering and manual analysis	Variable renaming, Control Flow Flattening, garbage code insertion
Crypter	Advanced form of packing, protects Payload with high-strength encryption, dynamically decrypts at execution	Achieve FUD (Fully Undetectable), file signature changes every time generated	Custom Crypter

How to see through packing: Packed executables present three abnormalities on the hard disk: content looks almost like garbage (loses regularity after compression/encryption), normal program error messages and API names and other readable text disappear, Windows function call list is extremely simplified (Stub only needs a few APIs to load the real program, other calls appear after unpacking).

Countermeasures: Sandbox dynamic analysis (let it run and observe behavior), Memory Dump (analyze after unpacking), behavioral detection instead of signature comparison.

Cyber Kill Chain Comparison Table

The Cyber Kill Chain proposed by Lockheed Martin breaks down APT (Advanced Persistent Threat) attacks into 7 stages:

Stage	English	Chinese	Description	Typical Activity
1	Reconnaissance	Reconnaissance	Collect target information	OSINT (Open-Source Intelligence), social media investigation, scanning public services
2	Weaponization	Weaponization	Create attack tools	Combine vulnerability exploit with Payload into a deliverable weapon (e.g., malicious PDF)
3	Delivery	Delivery	Deliver weapon to target	Phishing emails, malicious websites, USB drop
4	Exploitation	Exploitation	Trigger vulnerability	Exploit software vulnerabilities, zero-day attacks, user clicks malicious attachment
5	Installation	Installation	Implant persistent backdoor	Install RAT (Remote Access Trojan), create scheduled tasks, modify registry keys
6	Command & Control (C2)	Command & Control	Establish remote control channel	Connect back to C2 server, receive instructions
7	Actions on Objectives	Actions on Objectives	Achieve final goal	Data theft, data destruction, lateral movement, ransomware

Cyber Kill Chain vs MITRE ATT&CK

Comparison Aspect	Cyber Kill Chain	MITRE ATT&CK
Structure	Linear 7-stage chain	Tactics × Techniques matrix
Granularity	High-level attack process	Fine-grained techniques and sub-techniques
Applicable Scenario	Understanding overall attack process, post-incident backtracking	Writing threat detection rules, red/blue team exercises
Maintenance	Proposed by Lockheed Martin, updated less frequently	MITRE continuously updates, community contributions

Kill Chain defense thinking: Interrupting the attack chain at any stage can stop the attack, the earlier the stage, the lower the cost.
ATT&CK defense thinking: Build detection rules for each technique, increasing attacker costs and exposure risks.
The two are complementary: Use Kill Chain to understand the overall attack picture, use ATT&CK to build fine-grained detection capabilities.
Vulnerability exploitation techniques corresponding to each stage of Kill Chain: Exploitation stage common Buffer Overflow, ROP (Return-Oriented Programming); Installation stage common DLL Side-Loading.

Parentheses contain MITRE ATT&CK official tactic IDs, which can be queried for all specific techniques under that tactic at attack.mitre.org.

Kill Chain Stage	Corresponding ATT&CK Tactic	Supplement
Reconnaissance	Reconnaissance (TA0043)	One-to-one correspondence, collecting target information.
Weaponization	Resource Development (TA0042)	Acquire or build attack infrastructure and tools.
Delivery	Initial Access (TA0001)	Phishing, vulnerability exploitation, supply chain attacks, etc.
Exploitation	Execution (TA0002), Defense Evasion (TA0005)	Execute code after triggering vulnerability, and evade detection.
Installation	Persistence (TA0003), Privilege Escalation (TA0004)	Implant backdoor and escalate privileges to maintain access.
C2	Command and Control (TA0011)	Establish remote control channel.
Actions on Objectives	Collection (TA0009), Exfiltration (TA0010), Impact (TA0040)	Collect, exfiltrate data, or cause damage.

MITRE Defense-Side Frameworks:

In addition to ATT&CK (attacker perspective), MITRE has two defense-side frameworks:

Framework	Positioning	Description
MITRE D3FEND	Defender's Encyclopedia	Organizes defense techniques in a knowledge graph, precisely corresponding to ATT&CK attack techniques. Each D3FEND technique indicates which ATT&CK TTPs it can defend against; content covers Harden, Detect, Isolate, Deceive, Evict five categories of defensive actions.
MITRE ENGAGE	Active Defense and Adversarial Engagement	Focuses on Deception and adversarial engagement, guiding defenders on how to use decoys (Honeypot / Honey Token), misleading information, etc., as active means to expose TTPs, consume attack resources, and collect threat intelligence.

Positioning Distinction of the

On this page

iPAS Exam Preparation Notes - Information Security Engineer ​

Basic Concepts ​

Fundamental Principles and Terminology of Information Security ​

Information Ethics: PAPA Theory ​

Information Asset Classification Standards ​

Regulations and Compliance ​

ISO/IEC 27001 and ISMS Basic Requirements ​

ISMS PDCA Cycle ​

Audit Type (Three-Party) Comparison Table ​

Third-party Audit Certification Comparison Table ​

NIST CSF and NIST SP 800 Series ​

COBIT Governance Framework ​

ITIL Service Management Framework ​

GDPR and Taiwan PII Act Comparison Table ​

HIPAA Medical Data Protection Regulation ​

Information Security Responsibility Level Operations Requirements Table (A to E Levels) ​

Risk Management ​

Differences between Vulnerability, Threat, and Risk ​

Risk Assessment and Treatment Detailed Process ​

Risk Analysis Method Comparison ​

Risk Matrix ​

Delphi Expert Assessment Method ​

Score Matrix Method ​

Risk Quantification Formula ​

ROSI (Return on Security Investment) ​

FAIR Model (Factor Analysis of Information Risk) ​

Risk Treatment Strategy Comparison Table ​

Risk Terminology Supplementary Comparison Table ​

Shadow IT ​

Incident Management ​

Information Security Incident Severity Classification Comparison Table (Levels 1 to 4) ​

Information Security Incident Response (NIST SP 800-61) ​

Post-Incident Report ​

Cross-Platform Log Management and Forensics Path ​

Log Management Key Comparison Table ​

Digital Forensics: Order of Volatility ​

Chain of Custody ​

Memory Forensics ​

Business Continuity and Disaster Recovery ​

Backup Type Comparison Table ​

RAID (Redundant Array of Independent Disks) Comparison Table ​

Backup Site Type Comparison Table (Hot / Warm / Cold) ​

Data Storage Tiering (Hot / Warm / Cold) ​

BCP Test Type Comparison Table ​

Physical Security ​

Physical Security Control Measures Comparison Table ​

Environmental Control and Fire Suppression Systems ​

Electromagnetic Shielding (TEMPEST) ​

Cable Management Practices ​

Media Sanitization ​

Network Security ​

Network Attack Four Basic Types Comparison Table ​

Network Architecture and Protocol Comparison Table ​

PDU (Protocol Data Unit) Comparison Table ​

TCP and UDP ​

Common Port Comparison Table ​

TLS Positioning in OSI Model and HTTPS / HSTS ​

DNS Security ​

VPN (Virtual Private Network) Types and Protocols Comparison Table ​

IPsec Operation Mode Comparison Table ​

QUIC Protocol and HTTP/3 ​

NAC and 802.1X Authentication ​

Private IP and CIDR Subnetting ​

Network Segmentation ​

VLAN Security ​

SDN Security (Software Defined Networking) ​

IPv6 Security Considerations ​

Wireless Network Encryption Comparison Table ​

WPA2 4-Way Handshake ​

WPA3 and SAE ​

Purdue Model (OT / ICS Layered Security Architecture) ​

Linux / Windows Network Security Tool Comparison Table ​

Firewall Configuration ​

Network Diagnostic Tools ​

Network Sniffing and Packet Capture ​

Cryptography ​

Cryptography and Data Protection Technology Comparison Table ​

Symmetric Encryption Block Modes (ECB / CBC / CTR / GCM) ​

Nonce and IV (Initialization Vector) ​

iPAS Exam Preparation Notes - Information Security Engineer

Basic Concepts

Fundamental Principles and Terminology of Information Security

Information Ethics: PAPA Theory

Information Asset Classification Standards

Regulations and Compliance

ISO/IEC 27001 and ISMS Basic Requirements

ISMS PDCA Cycle

Audit Type (Three-Party) Comparison Table

Third-party Audit Certification Comparison Table

NIST CSF and NIST SP 800 Series

COBIT Governance Framework

ITIL Service Management Framework

GDPR and Taiwan PII Act Comparison Table

HIPAA Medical Data Protection Regulation

Information Security Responsibility Level Operations Requirements Table (A to E Levels)

Risk Management

Differences between Vulnerability, Threat, and Risk

Risk Assessment and Treatment Detailed Process

Risk Analysis Method Comparison

Risk Matrix

Delphi Expert Assessment Method

Score Matrix Method

Risk Quantification Formula

ROSI (Return on Security Investment)

FAIR Model (Factor Analysis of Information Risk)

Risk Treatment Strategy Comparison Table

Risk Terminology Supplementary Comparison Table

Shadow IT

Incident Management

Information Security Incident Severity Classification Comparison Table (Levels 1 to 4)

Information Security Incident Response (NIST SP 800-61)

Post-Incident Report

Cross-Platform Log Management and Forensics Path

Log Management Key Comparison Table

Digital Forensics: Order of Volatility

Chain of Custody

Memory Forensics

Business Continuity and Disaster Recovery

Backup Type Comparison Table

RAID (Redundant Array of Independent Disks) Comparison Table

Backup Site Type Comparison Table (Hot / Warm / Cold)

Data Storage Tiering (Hot / Warm / Cold)

BCP Test Type Comparison Table

Physical Security

Physical Security Control Measures Comparison Table

Environmental Control and Fire Suppression Systems

Electromagnetic Shielding (TEMPEST)

Cable Management Practices

Media Sanitization

Network Security

Network Attack Four Basic Types Comparison Table

Network Architecture and Protocol Comparison Table

PDU (Protocol Data Unit) Comparison Table

TCP and UDP

Common Port Comparison Table

TLS Positioning in OSI Model and HTTPS / HSTS

DNS Security

VPN (Virtual Private Network) Types and Protocols Comparison Table

IPsec Operation Mode Comparison Table

QUIC Protocol and HTTP/3

NAC and 802.1X Authentication

Private IP and CIDR Subnetting

Network Segmentation

VLAN Security

SDN Security (Software Defined Networking)

IPv6 Security Considerations

Wireless Network Encryption Comparison Table

WPA2 4-Way Handshake

WPA3 and SAE

Purdue Model (OT / ICS Layered Security Architecture)

Linux / Windows Network Security Tool Comparison Table

Firewall Configuration

Network Diagnostic Tools

Network Sniffing and Packet Capture

Cryptography

Cryptography and Data Protection Technology Comparison Table

Symmetric Encryption Block Modes (ECB / CBC / CTR / GCM)

Nonce and IV (Initialization Vector)

Asymmetric Encryption Algorithms